Spot on, when you ask "What is the purpose of the system?", you're hitting a key concept in Domain-Driven Design (DDD): bounded contexts. I was planning to introduce these concepts later in some post as initially I wanted to prepare this "building blocks" first. But it is a good opportunity to answer in a thread and start giving some practical advice from day 1 🙂.
Let's stick with the Bakery theme.
For the baker, the system’s function/purpose is focused on the recipe and baking process.
For the customer, it’s all about ordering fresh bread/cakes and getting good service.
And for the delivery team, it’s about getting that bread/cake to the customer on time (and in one piece!).
Each group operates within their own bounded context, i.e. they ONLY care about their specific part of the bakery system. The baker doesn’t need to worry about delivery logistics, the delivery team isn’t concerned with the recipe whatsoever, and so on.
In a nutshell, each context has its own "Why".
So congrats, by focusing on the system’s purpose you're already thinking in line with DDD principles. Each part of the system should be clearly defined by WHY it exists and what problem it's solving 🎯.
Let me quote George Box : "all models are WRONG, but some are USEFUL." It's not about creating a perfect model, but a useful one that serves its purpose within the right context.
thanks Marc, it helped me think out of the box when designing a system & ask myself why? what is the purpose of the system?
thanks, well said & in simple terms 🙂
Hey Boulos, thanks for your comment!
Spot on, when you ask "What is the purpose of the system?", you're hitting a key concept in Domain-Driven Design (DDD): bounded contexts. I was planning to introduce these concepts later in some post as initially I wanted to prepare this "building blocks" first. But it is a good opportunity to answer in a thread and start giving some practical advice from day 1 🙂.
Let's stick with the Bakery theme.
For the baker, the system’s function/purpose is focused on the recipe and baking process.
For the customer, it’s all about ordering fresh bread/cakes and getting good service.
And for the delivery team, it’s about getting that bread/cake to the customer on time (and in one piece!).
Each group operates within their own bounded context, i.e. they ONLY care about their specific part of the bakery system. The baker doesn’t need to worry about delivery logistics, the delivery team isn’t concerned with the recipe whatsoever, and so on.
In a nutshell, each context has its own "Why".
So congrats, by focusing on the system’s purpose you're already thinking in line with DDD principles. Each part of the system should be clearly defined by WHY it exists and what problem it's solving 🎯.
Let me quote George Box : "all models are WRONG, but some are USEFUL." It's not about creating a perfect model, but a useful one that serves its purpose within the right context.
thanks a lot for your reply 🙂
it really clarified things for me, specially to introduce me to the “bounded context” in the DDD 👏