[sbayeta]

(Not gp) I read this book more than a decade ago, when I was very inexperienced. The thing I remember the most, and I think the most valuable to me, is the idea of defining a shared domain language with the business domain experts, with a clearly defined meaning for each concept identified. For instance, what a "frozen" account exactly means, what's the difference with a "blocked" account. These are arbitrary, but must be shared among all the participants. This enables very precise and clear communication.

[darkerside]

I think that's the core idea. The layer on top the idea that that domain language should be expressed in an isolated core layer of your code. Here lies all your business logic. On top of that, you build application layers to adapt it as necessary to interact with the outside world, through things like web pages, emails, etc. as well as infrastructure layers to talk to your database, etc.

[zeroCalories]

At my job we have a shared glossary and data model that we use with business people, but do you really need a whole book on that?

[jameshart]

DDD is about a lot more than just defining what it calls ‘ubiquitous language’. It helps you figure out how to constrain which concerns of the language used in one domain need to affect how other domains think about those things - through a model it calls ‘bounded contexts’. Like, in your fraud prevention context, ‘frozen accounts’ might have all sorts of nuances - there might be a legal freeze or a collections freeze on the account, with different consequences; outside the domain, though, the common concept of ‘frozen’ is all that’s needed. DDD gives you some tools for thinking about how to break your overall business down into bounded contexts that usefully encapsulate complexity, and define the relationships between those domains so you can manage the way abstractions leak between them.

No silver bullet, of course, but, like most architectural frameworks, some useful names for concepts that give you the metavocabulary for talking about how to talk about your software systems.

This brief chapter from the O’Reilly Learning DDD book gives a good flavor of some of the value of the concepts it introduces: https://www.oreilly.com/library/view/learning-domain-driven-...

[zeroCalories]

Thanks for the explanation, I'll take a deeper look.

[aspenmayer]

In highly regulated industries like banking or other highly-secure environments, it’s a gradient between an internal wiki or FAQs etc, to what you have as an example of something more expansive and explicit, to an entire book, to an entire department or business unit for more important concepts that may vary between jurisdictions or be less explicitly defined, but no less important or impactful to the running of the business or group.