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?

3 Answers 3


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

  • 3
    @ Iulian> it's actually Plain Old CLR Objects, so that the F#, VB and Iron* crowd aren't left out. :D
    – Paul
    Mar 25, 2011 at 19:50
  • @Iulian but I have Entities, Repositories and Services, just because my Entities are POCOs it's not DDD anymore, what is it then ?
    – Omu
    Mar 25, 2011 at 19:57
  • 1
    @Omu DDD entities can be POCO classes. But if your entities are just a bunch of auto-properties then you are not doing DDD.
    – Ryan
    Mar 26, 2011 at 8:52
  • good to note "anemic domain" isn't bad if that's what you were aiming for (an n-tier with services layer). Mar 26, 2011 at 19:40

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.

  • @Victor Sergienko so am I using DDD at the moment or not ?
    – Omu
    Mar 25, 2011 at 19:13
  • @Omu - I'd say, if there's no logic in core objects - not (you were not clear on that; examples of class responsibilities for core entities and services would help). There rarely exists such a bodiless external power, a "stateless service doing something with object's data" in real world. Mar 26, 2011 at 0:37

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.

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.