DDD + POCO does this makes sense?

Question

DDD promotes rich domain models with behavior in it, POCO naked objects without any objects in it. Is it possible to have them both combined?

I have a Multi Layer Solution

• Core - has POCO Entieties, interfaces for Repositories and Services
• Data - Repository implementations
• Service - Service Implementations
• Infra - IoC Locator/registrar, viewmodels, (could be merged to webui)
• WebUI - asp.net mvc presentation layer

I was saying that I use DDD but recently I've been told that I'm not because my Entities don't have behavior, is this true?

Answer 1

POCO stands for plain old c# objects. It comes from the java equivalent POJO. It's just a hip name to show the world that not everything has to be a derived class. POCOs are not necessarily DTOs, they can be full blown objects with behavior and state and clild POCOs, while DTOs only have state.

Now about your domain - if as you say you are trying to do DDD but your entities don't have behavior than you've been bitten by the anemic domain model anti-pattern. Grab Mr. Evans book on Domain Driven Design and after reading it start planing your model refactoring, preferably with your domain expert.

Also worth mentioning that the anemic domain model is not by itself an anti-pattern, only when you try to do DDD and end up with and anemic model. So if your apps are doing fine and your users are happy, don't bother refactoring for the sake of DDD, just keep it in mind for the future.

This link might help you identify other problems

Answer 2

If your core entities are plain DTOs, then it might be considered an anemic domain model.

I never liked the idea of moving logic to services - looks like a crutch to fix ugly persistence architecture.

Answer 3

POCO and DTO are two different things. DDD experts used POCO to differentiate from the initial EntityFramework model where your Entities had to extend EntityObject or implement a specific interface. As of 4.1 Entity Framework also supports POCO for persistence allowing for richer behavior and a more domain-centric approach to developing your business objects. DTOs are plain dumb data objects that don't have behavior (usually for transfer between two layers of an application).

Personally, I don't use DTOs at all anymore, when my UI communicates with the business layer, I expect View Models which have interaction logic embedded in them along with the data. This approach works with ASP.NET MVC applications as well as Rich/Smart Clients accessing restful services over the web. Behind the Service Layer, queries from the client are translated from Domain Entities to VMs and inbound commands are translated to actions against the Domain. Thus the client is shielded from the details/intricacies of the Domain and the Domain isn't corrupted by client/display concerns.