Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Mar 26 '11 at 10:34

This question came from our site for professional and enthusiast programmers.

add comment

3 Answers 3

up vote 12 down vote accepted

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

share|improve this answer
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 '11 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 '11 at 19:57
    
@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 '11 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). –  qes Mar 26 '11 at 19:40
add comment

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.

share|improve this answer
    
@Victor Sergienko so am I using DDD at the moment or not ? –  Omu Mar 25 '11 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. –  Victor Sergienko Mar 26 '11 at 0:37
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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