Weekly Questions - Domain-Driven Design
Questions and discussions by the community
Does DDD replace E-R diagrams and planning?
With DDD concepts you are modelling the business language used to define your domain. Not the models directly.
That’s the difference.
It’s okay to skip the language part. But whoever on your team ends up doing DDD activities will have to re-do the important steps that were missed.
You don’t want an engineer re-discovering business jargon once they are knee-deep in code. Re-speccing at that tactical stage should be avoided because it can cause remodelling upstream or in other schemas, like a database.
DDD modelling answers questions like
”did we name this correctly?”,
“should we have it organised on this axis or that one?”,
“which axis is the main source of conversation for the business?”
If your starting point are models that have to go in a db schema, it’s too late.
Should we always plan using DDD?
First of all, absolutely stop using it if it's not useful for you.
DDD is the equivalent of buying your own subsidiary accounting and legal firm to handle your paperwork. It is a holistic organisational approach. It requires buy-in and commitment.
Most small domains don't need that.
But "small" is relative here - benefits of DDD when applied strategically are immediate and quite practical applied even on a 5-10man project.
You can’t just wing-it. However, you can start with your enthusiasts with a simple Event Storming or modelling workshop.
But it has to start at the org level. As Vedran B. mentioned, if you start with your DB, you're way past the mark for using DDD.
Strategic conversations using event storming or modelling should've happened before the team even gave a name for the project.
My ORM has Repositories and Entities… is this DDD?
Strictly speaking, no.
DDD on the code-level primarily focuses on bounded contexts and aggregates. Repositories are collections of Aggregates. Entities are usually left to the particular detail of specific aggregates. Sometimes they’re small enough to be eagerly loaded with the aggregate.
In other cases the aggregate can defer loading to an entity manager or other mechanisms. The important point is that Repositories are about persisting and finding based on business use cases. They are not dumps for your SQL table’s search queries.
There is a very good talk on this somewhere on youtube but I seem to have misplaced the link. I’ll update it at a later point!
Edit: Found it - https://arnolanglade.github.io/talks/forum-php-2018.html
Sadly it’s in french, but the website has the valuable slides in english. This talk is gold!
What’s an Aggregate?
Unfortunately, the blue and red book are quite nebulous on this detail. It takes a few re-reads to really capture a lot of nuance that is being captured in a few sentences that are way too easily overlooked.
To not bore you with quotes, appendixes and updated book revisions, here’s an up-to-date account on it from last year’s DDD Europe.
Sources
Private coaching slack
Client work