Domain Logic in Service Layer - how best to reference it as well as expose it

Question

I am designing an enterprise solution which consists of modularized products within a product range using Entity Framework code first to define the domain model and provide the data access.

e.g. Solutions:

ProductRange.Authentication
ProductRange.Gateway
ProductRange.OrderSystem
ProductRange.MarketingSystem

Each of these products (solutions) will have similar layers, currently:

Projects in each solution:

ProductRange.OrderSystem.Model (contains code first POCOs)
ProductRange.OrderSystem.DataContext (contains the dbContext)
ProductRange.OrderSystem.DataAccess (contains the Generic Repository)
ProductRange.OrderSystem.Service.DomainLogic (contains business logic)
ProductRange.OrderSystem.Service.ApplicationLogic (contains application logic)
ProductRange.OrderSystem.Presentation.AdminWebsite
ProductRange.OrderSystem.Presentation.CustomerWebsite

Some of the products will need to access the domain logic of another product, especially they will all need to access the ProductRange.Authentication but also ProductRange.MarketingSystem will need to query ProductRange.OrderSystem

I am thinking to expose the domain logic between products in the range via a WCF service. But I will also need to reference the product locally (e.g. creating project references).

How should I go about implementing this? Should I create a WCF service e.g. ProductRange.OrderSystem.WCF which calls the domain logic and exposes it or should my domain logic itsself be a WCF service? If the latter, would I always have to reference my domain logic via the WCF, even from the local ApplicationLogic?

I guess I am looking for some guidance about what layers to have and how best to provide inter connectivity between the solutions.

Asked: http://programmers.stackexchange.com/questions/212514/domain-logic-in-service-layer-exposed-as-wcf-service — Dan Cook, Sep 25 '13 at 12:49

Omer Faruk Zorlu · Answer 1 · 2014-08-04T21:03:40.023

You can use a single( or multiple) layer to expose your pocos as datacontracts and service contracts.

for example:

ProductRange.Server.DataContracts
  Product
  AuthenticationInfo

ProductRange.Server.ServiceContracts
  IOrderService
  IAuthentication
   Auth(AuthenticationInfo info):AuthenticationResult

ProductRange.Server.Services
 OrderService
 AuthenticationService(implements IAuthentication interface)

In the client side you can refer this project(only data contracts and service contracts) and create transparent proxy over interfaces like:

var serviceProxy = SomeHelper.CreateServiceProxy<IAuthenticationService>();
var result = serviceProxy.Auth(new AuthenticationInfo());

In addition: you can use your poco classes as a data contracts. If you want to better connectivity then you choose a binding(like a net.tcp) for your requirements.

Domain Logic in Service Layer - how best to reference it as well as expose it

1 Answers1