Home/ Questions/Q 8333037
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T02:53:20+00:00

I have a Domain that I generate using Entity Developer. This creates all of

  • 0

I have a Domain that I generate using Entity Developer. This creates all of my Entities and my Database tables. I use NHibernate to populate my Entities which are exposed via Repositories. I then have a services layer that aggregates the Repositories into useful services. This layer is used in two ways. One, I use services as my only means of communication to and from my web layer and I want to someday use the services for WCF. Right now, I’m working on my web layer and I’m trying to figure out the best way to communicate with my services. My services are currently returning Entities. My web layer is grabbing these Entities via the services in the controllers. This is probably not very DRY/DDD. I’m assuming my services layer needs to interface via DTO’s. DTO’s would be perfect for my WCF services. As for my Web layer, I’m assuming that I would take the DTO’s that are returned from my services layer and I would want to map those to View Models (I’m using ASP.NET MVC 3).

So this is what my architecture would end up looking like:

Domain
  Entities
  Repository Interfaces
Infrastructure
  NHibernate
  Concrete Repositories
Services
  DTO's
  Concrete Services
  Service Interfaces
  IIS hosted WCF
Website
  ViewModels

And I would either use Automapper or ValueInjecter to do my mappings (probably ValueInjector due to the ability to flatten and unflatten my Entities/DTO’s.

So is this overkill? The system I’m using this architecture is quite large (I’m rewritting everything). Am I doing it right? Everything is decoupled dependency-wise with Ninject because I could see wanting to change out any part of the system at any time. Any thoughts, ideas or criticism is very welcome and appreciated.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    This is a common architecture and works well in practice. One central benefit is encapsulation – your domain is encapsulated by a service layer (application services in DDD).

    As far as WCF services, I believe a more appropriate term for them is adapter. This is based on the hexagonal architecture where you application service layer is at the core and WCF adapts HTTP (or other binding) to it. With this in mind, application services should be implemented in an adapter agnostic way. This means no WCF specific attributes or data contracts. The WCF adapters in turn are thin layers around application services. Some may consider this overkill because of the added layering, but I’ve found it beneficial because it keeps the application layer free of technology specific concerns.

    Whether this architecture is overkill depends on the project. One way to answer that question is to determine whether the application is mostly CRUD in which case DDD is overkill and it may be better to use a technology which facilitates reading from the database and exposing the data directly as a service.

    Take a look here for a more in-depth treatment of services within DDD.

    • 0