I always had this idea of DDD as 2 parts 1- subdomain : - the process of breaking down the business domain into subdomains - sales - payments 2 - bounded context - the process of breaking down the subdomain into logical modules in code in which there my be 1 to 1 or 1 to many relations - 1 : 1 relation [ sales as a subdomain : sales as a bounded context in code ] - 1 to n [ sales as a subdomain : sales provider BC- sales report BC]
You are not entirely wrong about this and generally what you propose might work in practice quite well. However, according to Eric Evans and the DDD theory, domains (or sub-domains) are conceptually different in regards to the bounded contexts. A domain or sub-domain proposes some problems that need to be resolved by writing code. So the domain or sub-domain belongs to a so-called problem space. It often also reflects an organizational structure of the company for which the app is developed. The domain model is totally different, as it comes with the solution to a certain problem. So, it belongs to the solution space. The bounded context as well, as it is a way to break down the solution into different area. It's true that at an very high level, sub-domain and bounded context seem to coincide. Eric Evans, however, has a very plastic description of the needed distinction. Think of the sub-domain as an empty room of a certain surface. The task is to cover the floor. So, ideally you would be able to get one carpet that corresponds to the room's surface. However, in practice, you might be able to solve the problem with two carpets, or three, depending on different variables. The room is the sub-domain. The carpet is the bounded context. You spot the difference? Also, according to DDD theory, the ideal case is where you'd have only one bounded context per sub-domain.
@@Codewrinkles So the Sales will be the problem space (sub-domain aka the room), and having a sales service (single carpet) or breaking the service into small ones like sales report / provider as many carpets, have i got this right 🤔 ?
One problem with DDD is that there's really no good answer for all use cases. Even more, each business will reflect the problem space differently and hence different solution approaches. However, to give you an answer to your question we need to also bring in the concept of ubiquitous language which is fundamental for DDD. As a principle, the language and wording that the business uses, needs to be reflected in code using the exact same wording/language. Therefore, according to DDD and using your Sales example: - We can agree that Sales is a sub-domain (the room) - If in the Sales department/business there are people/teams that use a certain word to describe a sale, then we need only one bounded context. If in that department there are people/teams that use different words for the same thing and also with a slightly different understanding, then you would have more bounded contexts. I was never a sales guy and I can't think of a meaningful example. But to spin off from your initial example, if everybody in Sales understands the same thing when they say "report", then there would be only one bounded contexts. If In Sales, the word report is used with a different meaning and different business processes, then there would be several bounded contexts. As mentioned in the video, bounded contexts are not there to just break down routines in sub-routines. They represent boundaries of applicability, therefore a boundary within which a certain business concept is understood in exactly the same way. The moment you notice that a certain business concept is used differently within the business, you need to create bounded contexts.
Thanks for your videos, I've got a couple of questions: 1 - how do you manage to keep the same ID for the product between bounded contexts. Is this just some kind of configuration on the mapping with Entity Framework or is something to be nanaged by business logic? In this second case I immagine that the Catalog BC will be responsible for creating a new Product and publishing a corresponding event that the others intrested BC will consume and write the corresponding record with the same ID on their side. Is it Correct? 2 - Wwhat happens when you need to show data from different BC, like for example on an ecommerce page that lists all the products of a specific category with theirs price and average stars? The aggregation part becomes harder and requires more queries. In your experience, is this really a problem that needs to add a separate read model with the added complexity of keeping it updated or in most cases having multiple queries doesn't affect much the performances?
1. You don't need to have the same id in each Bounded context. You just need a property on the Product in one bounded contexts, that references the ID of the product from the original one. This is one possible workaround. However, the challenge you mentioned is one of the reasons why microservices apps (usually those apps make DDD valuable) are using GUIDs as identifiers. In most databases you can set GUID identifiers on your own, while ints are usually database generated. 2. The idea of read models is important. And that's why when you have complex enough applications that make the DDD complexities worth, you'd usually work with read models and write models and full CQRS. And commands you'd handle through EF for instance (because it has change tracking and it's useful) and reads you habdle with raw SQL or lightweight ORMs like Dapper. As a concluion: Eric Evans's book's subtitle is "Tackling complexity in the heart of software". This is also an indication that going full DDD introduces a lot of complexity and if your are building simple and even mid-sized apps it's not worth going full DDD. This doesn't mean, however, that you can't use some of the patterns and techniques proposed in DDD.
I always had this idea of DDD as 2 parts
1- subdomain :
- the process of breaking down the business domain into subdomains
- sales
- payments
2 - bounded context
- the process of breaking down the subdomain into logical modules in code
in which there my be 1 to 1 or 1 to many relations
- 1 : 1 relation [ sales as a subdomain : sales as a bounded context in code ]
- 1 to n [ sales as a subdomain : sales provider BC- sales report BC]
You are not entirely wrong about this and generally what you propose might work in practice quite well. However, according to Eric Evans and the DDD theory, domains (or sub-domains) are conceptually different in regards to the bounded contexts. A domain or sub-domain proposes some problems that need to be resolved by writing code. So the domain or sub-domain belongs to a so-called problem space. It often also reflects an organizational structure of the company for which the app is developed.
The domain model is totally different, as it comes with the solution to a certain problem. So, it belongs to the solution space. The bounded context as well, as it is a way to break down the solution into different area.
It's true that at an very high level, sub-domain and bounded context seem to coincide. Eric Evans, however, has a very plastic description of the needed distinction. Think of the sub-domain as an empty room of a certain surface. The task is to cover the floor. So, ideally you would be able to get one carpet that corresponds to the room's surface. However, in practice, you might be able to solve the problem with two carpets, or three, depending on different variables.
The room is the sub-domain. The carpet is the bounded context. You spot the difference? Also, according to DDD theory, the ideal case is where you'd have only one bounded context per sub-domain.
@@Codewrinkles
So the Sales will be the problem space (sub-domain aka the room), and having a sales service (single carpet) or breaking the service into small ones like sales report / provider as many carpets, have i got this right 🤔 ?
One problem with DDD is that there's really no good answer for all use cases. Even more, each business will reflect the problem space differently and hence different solution approaches.
However, to give you an answer to your question we need to also bring in the concept of ubiquitous language which is fundamental for DDD. As a principle, the language and wording that the business uses, needs to be reflected in code using the exact same wording/language.
Therefore, according to DDD and using your Sales example:
- We can agree that Sales is a sub-domain (the room)
- If in the Sales department/business there are people/teams that use a certain word to describe a sale, then we need only one bounded context. If in that department there are people/teams that use different words for the same thing and also with a slightly different understanding, then you would have more bounded contexts.
I was never a sales guy and I can't think of a meaningful example. But to spin off from your initial example, if everybody in Sales understands the same thing when they say "report", then there would be only one bounded contexts. If In Sales, the word report is used with a different meaning and different business processes, then there would be several bounded contexts.
As mentioned in the video, bounded contexts are not there to just break down routines in sub-routines. They represent boundaries of applicability, therefore a boundary within which a certain business concept is understood in exactly the same way. The moment you notice that a certain business concept is used differently within the business, you need to create bounded contexts.
very usefull. very good thank you very much in this world and hope all best wishes in the future worlds
Thanks for your videos, I've got a couple of questions:
1 - how do you manage to keep the same ID for the product between bounded contexts. Is this just some kind of configuration on the mapping with Entity Framework or is something to be nanaged by business logic? In this second case I immagine that the Catalog BC will be responsible for creating a new Product and publishing a corresponding event that the others intrested BC will consume and write the corresponding record with the same ID on their side. Is it Correct?
2 - Wwhat happens when you need to show data from different BC, like for example on an ecommerce page that lists all the products of a specific category with theirs price and average stars? The aggregation part becomes harder and requires more queries. In your experience, is this really a problem that needs to add a separate read model with the added complexity of keeping it updated or in most cases having multiple queries doesn't affect much the performances?
1. You don't need to have the same id in each Bounded context. You just need a property on the Product in one bounded contexts, that references the ID of the product from the original one. This is one possible workaround.
However, the challenge you mentioned is one of the reasons why microservices apps (usually those apps make DDD valuable) are using GUIDs as identifiers. In most databases you can set GUID identifiers on your own, while ints are usually database generated.
2. The idea of read models is important. And that's why when you have complex enough applications that make the DDD complexities worth, you'd usually work with read models and write models and full CQRS. And commands you'd handle through EF for instance (because it has change tracking and it's useful) and reads you habdle with raw SQL or lightweight ORMs like Dapper.
As a concluion: Eric Evans's book's subtitle is "Tackling complexity in the heart of software". This is also an indication that going full DDD introduces a lot of complexity and if your are building simple and even mid-sized apps it's not worth going full DDD. This doesn't mean, however, that you can't use some of the patterns and techniques proposed in DDD.
Not be be meta, but *Discipline* Driven Design would've been a better, more descriptive term.
Agreed
Lovely video. You say “kind of” a lot 😅
And also "basically". I try my best to avoid those expression.