> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ...
> DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation. It doesn’t prescribe methods, or practices, and even the patterns in the book1 are meant to be illustrative rather than a final set. ...
> That makes DDD notoriously hard to define.
I don't know anything about DDD, but if you can't concretely describe it and how it's different to how teams naturally work together, how can it be actionable and what stops it becoming another cargo cult when nobody can agree on what it is?
They are the probably the best concrete and actionable introductions to DDD out there, and do a very good job of separating practical DDD from the OOP dogma that it is sometimes tied to. The book uses F# as it's language to implement and demonstrate its examples, but most of the concepts are presented in a language agnostic way.
I find it hard to understand how you'd get the essence of the idea from some of these descriptions, I was lucky enough to be at OOPSLA when Erics book came out and he had a session on it, I think he explained it pretty well, not sure if there are online presentations of his that are good, his book is good, but has a lot of extra more "technical" stuff to deal with how to implement it.
I actually think that this perception is what has caused most of the architectural overkill mentioned in this thread. People want something "actionable", so they extract the specific patterns.
The most important part of DDD is the principles. It's a way of looking at the world and at problems, of seeing things first and foremost from the business perspective. How you apply those principles to achieve that perspective must vary dramatically from project to project, which means that the details of action are left to you to decide.
> DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation. It doesn’t prescribe methods, or practices, and even the patterns in the book1 are meant to be illustrative rather than a final set. ...
> That makes DDD notoriously hard to define.
I don't know anything about DDD, but if you can't concretely describe it and how it's different to how teams naturally work together, how can it be actionable and what stops it becoming another cargo cult when nobody can agree on what it is?