Sunday, March 11, 2007

An interesting example that DDD confuses people

An interesting example that DDD confuses people

The point I am trying to make is: Entities should never depend on “services” and “repositories”. “Services”, “Repositories” have to be procedural-oriented. “Rich” model cannot be totally OO. This is not even because of TDD; it is because of distributed computing. DDD confuses people about it, and that is wrong.

You may say, it is because people are learning in DDD; I do not believe so, I believe DDD confuses people by the so-called “Rich domain model”.

Here is the example.

ayende has a very good post here:

In general, I agree with him mostly, including aop, or mapping etc -- the approach is lightweight java approach. I know his work is kind of competing with springframework, which is also lightweight-java-like, but heavier. I like ayende’s approach better – the lighter, the better. As a matter of fact, I feel his approach is still too heavy – because of WF, now I believe the best way is CSLA-based – but I tear it apart, I use command pattern for “services”, “CRUD daos”, “controllers” (see my post Note that I mentioned window development, simply because of its window databinding support; the core design is good for both windows and web).

Ayende is closer to DDD than me. I guess that is simply because of the fact that his everyday work has more “infrastructure” factors than application developers like me, who routinely needs to leverage data in databases to get the application logic right; however, it seems that he has some reservations on DDD also, not sure though. However, the following exchanges are very interesting to support my point of view on DDD (again, please read the whole blog thread at -- I only copy the a very small part here, hope it is “reasonable use”).

OK, now, really, here is the example:

@Ayende, I'm handling it the same way, but i have some doubts about where to put DAO (or Repository) calls? I can do it like you showed above, add service layer and place all calls there, but i also can inject my DAOs directly in domain objects, making service layer is needless (and still keeping domain objects testable). I just can't decide, probably because of lack of experience. I know you prefer services, but what you think about second approach? :)
# re: Entities, Services and what goes between them... 3/1/2007 10:46 AM Ayende Rahien

@Andrew,The other approach, I feel, gives too much responsibilities to the domain objects. They are still testable, but I feel that this makes the significantly more complex. I am placing the repository calls in both services and controllers at the moment.


Post a Comment

Subscribe to Post Comments [Atom]

<< Home