As a newbie developer I’ve been thinking a lot lately about where to put responsibilities and behaviour in systems I develop. It seems quite common for most developers to default to the DTO pattern and just dumb objects. Fine grained value objects might not be real DTOs, but it is in the same tradition of not having behaviour in the objects. I see some proponents mean it’s bad OOD, and it probably is. I’m not just sure what will work best for me yet. 😉
I was reading this post on Jon Tirsens blog on the usage of DTOs when I came across Domain Driven Design by Eric Evans. I’ll have to pick it up some day. I just have to finish up reading for JCP and J2EE without EJB first. 😉
6 replies on “Domain Driven Design”
It is a fantastic book, one you read, nod, go work, reread months later, see things you never saw, etc.
-Brian
Agreed. Domain Driven Design is a great book. Together with “The Pragmatic Programmer” that book stands out against most other litterature.
I was just in the process of writing a long reply to this when I actually read your link to Jon Tirsen’s comments on DTOs.
When he talks about not using DTOs unless it’s in a “distributed system”, there in lies the confusion for many.
Until recently, any application involving EJBs had to be considered to be a distributed system, because only remote interfaces existed, and you could not guarantee what optimizations your application server may or may not make for locally accessed objects.
Hence the rise of the DTO pattern.
Even today, I would probably recommend that if you’re using EJBs, use DTOs. It will also potentially make life easier for you if you decide to migrate away from EJBs to a lightweight container.
However, if you’re not using EJBs or RMI, then you really do have to question why you would want or need to use DTOs.
Jumping on the DTO bandwagon
There’s a lot of chatter at the moment about the use and abuse of Data Transfer Objects (DTOs).
See here,
Not using EJBs so I really don’t need DTOs. And I don’t have either, but what I do have is value objects with no behaviour. At the present time we have a clear distinction between our business layer and value objects that sort of models our domain. I’m not sure which way to go on this. That’s probably why I should read the book. 😉
Domain Driven Design is a fine introduction to the “why” of domain modeling, but when it gets into the details of “how”, it jumps the track. I highly recommend “Streamlined Object Modeling” by Nicola, Mayfield, and Abney for an outstanding book on “how” to build good domain models.