Eric Evans: What I've learned about DDD since the book
Why Stack Overflow recommends it
Stack Overflow users link it when answering DDD questions about aggregates, domain events, bounded contexts and SOA, since it is Evans's own updated take on the book's patterns.
Recommended by 4 people across 5 different months, 2013 to 2019.
What it is
A recorded 2009 QCon London talk, re-recorded at a DDD-NYC meetup, in which Eric Evans reflects on what he learned about Domain-Driven Design in the years after publishing his book. He shifts emphasis toward ubiquitous language, context mapping and core domain, adds domain events, and clarifies how DDD fits with SOA. It assumes prior knowledge of DDD.
What people said
Recommends Adrian Thompson Phillips · 2013-07 · Stack Overflow · on “Do I need to be a design patterns expert before I dive into Domain Driven Design?”
I read the blue book [Evans], the red book [Vernon] and occasionally pop into this tag on StackOverflow. The book by Evans is very high level in some aspects and covers more than just code. The book by Vernon covers the building blocks of DDD an item at a time, using examples from a fictitious software product as an example: Domain-driven Design: Tackling Complexity in the Heart of Software [LINK] Implementing Domain-Driven Design [LINK] There's also the video: Eric Evans: What I've learned about DDD since the book [this video] As for design patterns, the DDD material refers to lots of design patterns. Some existing design patterns work very well with DDD. You can pick these up as you encounter t
Recommends VoiceOfUnreason · 2016-06 · Stack Overflow · on “DDD, Aggregates and Entities”
Yes, it's a consequence of treating an aggregate as a consistency boundary. See Chapter 6 for the discussion of aggregates. Also, review what Evans has to say about aggregates in this talk: [this video]
Recommends Dimos · 2018-04 · Stack Overflow · on “Service Oriented Architecture & Domain-Driven Design”
I am really really late in this, but I would like to add the following in the very good answers by everyone else. DDD is not in any conflict with SOA . Instead, DDD can help you maintain a better Service Oriented Architecture. SOA promotes the concept of services, so that you can define better boundaries (oh, context boundary is also a DDD concept!) between your systems and improve the comprehension of them. DDD is not about applying a set of patterns (e.g. repository, entities etc.). DDD is mostly about trying to model your software , so that all the concepts (i.e. classes in case of object-oriented programming) align directly with concepts of the business. You should also check this video
Recommends Myk · 2019-05 · Stack Overflow · on “Am I allowed to have "incomplete" aggregates in DDD?”
I realize this answer is 11 years old... But I believe one is supposed to model their aggregates based on what domain experts say. So in case one misinterpreted what the domain experts said, a huge aggregate should be remodeled into smaller that match the vision of domain experts better. In case, a huge aggregate is consistent with the mental model of domain experts -- formally speaking DDD dictates it be huge. Bad luck, I guess. Actually, Eric Evans mentioned this problem and possible solutions in a talk: [this video]
Recommends VoiceOfUnreason · 2019-12 · Stack Overflow · on “How low-contention transaction related to Aggregates in DDD?”
And there is no any relationship with Cargo You may have overlooked one of the earlier modeling constraints; that handling events are uniquely identified by a tuple of completion time, event type, and the Id of its Cargo . So given any handling event, you can use the cargo identifier to look up the appropriate cargo, and likewise given any cargo you can get a list of all matching handling events. I cant understand the relationship between low-contention and HandlingEvent Aggregate. That is Not Your Fault[tm]. Evans, writing in 2003, is missing an important concept: Domain Event [LINK] . You'll find him discussing that idea in front of DDD-NYC in 2009 [this video] . It may also help you to orient
Cites VoiceOfUnreason · 2017-04 · Stack Overflow · on “Is it safe to publish Domain Event before persisting the Aggregate?”
I have seen 2 different approaches of raising Domain Events. Historically, there have been two different approaches. Evans didn't include domain events when describing the tactical patterns of domain-driven-design; they came later [this video] . In one approach, Domain Events act as a coordination mechanism within a transaction . Udi Dahan wrote [LINK] a number of posts describing this pattern, coming to the conclusion: Please be aware that the above code will be run on the same thread within the same transaction as the regular domain work so you should avoid performing any blocking activities, like using SMTP or web services. event-sourcing [LINK] , the common alternative, is actually a very dif