,
5 tweets,
1 min read
Read on Twitter
Domain-driven design can seem really complicated with lots of jargon, etc.
At-the-end-of-the-day, in a nutshell, it's a divide-and-conquer approach.
The #1 thing is to divide your business into smaller "chunks". Each chunk is easy to deal with + understand (thread)
At-the-end-of-the-day, in a nutshell, it's a divide-and-conquer approach.
The #1 thing is to divide your business into smaller "chunks". Each chunk is easy to deal with + understand (thread)
BUT, to be able to do that well and in a way that benefits the business, you need to understand....the business.
What are the moving parts of the business?
Who are the people?
What do they do? When do they do it? Why do they do it?
What are the processes?
What are the moving parts of the business?
Who are the people?
What do they do? When do they do it? Why do they do it?
What are the processes?
DDD drives software professionals to learn about the business so that they can walk hand-in-hand with the people who matter and will use the software in the end.
Each "chunk" can do what it wants. Each can be complex or simple. That's a huge benefit: each chunk (bounded context) can be built as efficiently or thoughtfully as needed!
The implementation of each BC is not important compared to the high-level detail + the interactions between BCs.
One might use basic CRUD, another event sourcing, etc. But from an initial design POV, the needs of each BC are independent and matter in implementation.
#DDD
One might use basic CRUD, another event sourcing, etc. But from an initial design POV, the needs of each BC are independent and matter in implementation.
#DDD
