I read Eric Evans’ book on DDD years ago and fall asleep with it. Didn’t really took much value from it. Last year I read Vaughn Vernon’s book on IDDD and I found it more interesting because of the code examples but still too abstract. Too much prose, too thick. One problem with both books is that their written English style is quite sophisticated for a non-native English speaker like me. But I believe there is a lot of value in DDD, so I’ve read it several times, on kindle and later on paper. My feeling with DDD is still a bit frustrating. I find many contradictions in Vernon’s book. But there is a lot of valuable advise in the book I want to benefit from. I should be able to get more value from the book.
This is the first of a series of posts to myself with the idea of better study the subject, trying to summarize the heuristics that I think are going to be more useful for me and hoping the return the investment of time. I want to fix the ideas that I find good.
The following statements are not necessarily in the book literally, this is just what I have in mind and it could just be my interpretation.
Along the book it’s advised not to model the domain based on infrastructure concerns, tools or frameworks. However there are sentences where I think it reads: depending on the persistence mechanism you might choose to model a concept as an entity or as value object. Aggregates are specially contradictory. “Aggregate is synonymous with transactional consistency boundary”. Well, transactionality is purely infrastructural so what’s the point with aggregates? I believe the chapter on aggregates has very little to do with modeling, but it can be really useful if I can extract a list of architecture/infrastructure problems and solutions, recipes. I just need to extract a list of architecture solutions from that chapter, will do so in an upcoming post.
The distinction between Application Service and Domain Service is hard to see for me. I understand that an Application Service should not contain domain logic, however I am not sure anymore what “domain logic” is after reading some examples of Application Services. I have to dig further into it.
Choosing an Entity or a Value Object is still a hard decision. Apparently Value Objects should be used more often than they are, developers tend to abuse Entities and end up with anemic models. However my impression is that entities are used way more than values along the book. After reading the chapter on Value Objects for the first time, I thought I got it – if I could consider two objects to be equivalent when they had the same field values, they must be value objects. After working with experienced DDD developers in my team and reading the book again, I see I was wrong. I’ll focus on the distinction between entities and values in upcoming posts.
This post is going to be updated as I encounter more paradoxes (from my current understanding).