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:


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)

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.

  • What's the different between application and domain logic in your example?
    – CodeART
    Commented Sep 27, 2013 at 13:15

2 Answers 2


Here is my two cents worth, I tried to find support for my "WCF is just an interface" on google but have had no luck. I will try again this evening if I get the chance.

The way I was taught and have always approached this is that WCF is just another interface (using the term interface in the way that "GUI" uses it not as the .Net keyword), specifically a way to access code over a network (or internet etc.) I always have a separate class library(s) that the WCF service delegates to for all functionality not related to WCF.

That class library is designed to be usable from any .Net code on the same machine.

The WCF service will do the work to make the library consumable by a variety of languages over the wire. It may translate .Net types to more generic types, lists to arrays for example, or it may add compression for performance reasons.

So if you are consuming the library from .Net code on the same machine I would go directly against the class library. You may want to install this in the GAC for version control.

Of course if the service is stateful then you may want to code against it for simplicity's sake.

Edit. I thought of another reason you might want to bypass WCF locally. For performance reasons a WCF Client should never be "chatty" it is better to make fewer calls that pull in more data, running against a DLL this limitation is not important. So your class library could expose methods that you would not want to expose over WCF.


What you have to ask is, what model is my code going to execute in? If it is going to execute wholly within a single machine, there's no point in a WCF service. If it is going to execute in a networked model, placing logic in a WCF service for the clients to call makes sense IF the client(s) will not have access to a resource (e.g. database)

Practically speaking, your domain logic classes should be exposed as interfaces to the consuming clients, so that if you decide to change your implementation from single machine to WCF or REST your consumer classes won't know the difference. -PatFromCanada alluded to this

Your 'layers' should be triaged along the same principle, only create separate projects for separate files to be deployed. Separate 'layers' by namespaces

  • Why? The System may be single-tier but peer-to-peer in which case the client is the WCF service. Alternatively, n-Tier topologies that share data amongst clients (irrespective of whether there is a database) will have a server WCF service. With regards to resources, you should avoid having clients that talk directly to a database due to scale-ability concerns hence the need to a WCF service containing your logic.
    – Deleted
    Commented Apr 28, 2014 at 7:13
  • Micky, I'm not sure what you're asking. I covered the need to separate contracts and implementations so that specific cases could be implemented as needed with little breaking changes. There shouldn't be an automatic assumption that clients must avoid talking to the database, there may not be that many clients, and simply having a WCF service does not eliminate the load of many clients. Design decisions such as caching, load balancing, sharding etc. do this.
    – Kevin
    Commented May 6, 2014 at 13:22
  • I said "avoid" not "automatic". A well-designed WCF service can purposely throttle incoming requests so as to avoid thrashing not just the back-end but also the DB-layer. Architectural (not "design") decisions such as caching, load-balancing and sharding always help, but a better designed system scales even better without these expensive cliched options. The use of queued messaging instead of RPC for instance - a far more efficient choice. soapatterns.org/design_patterns/asynchronous_queuing
    – Deleted
    Commented May 10, 2014 at 14:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.