![]() You need to find your way.Īs I mentioned, I try to keep clear boundaries between my bounded contexts. Besides that I ask questions if I don't understand something or I am uncertain what they have in their minds during discussions. I also keep in mind which part of the process they're dealing with or talking about. What works for me is listening to domain experts and learning their language. that you have to catch those differences. ![]() Such as mentioned customer might mean two different things in two different contexts. Definitions of terms are clear within given bounded context. The language comes from the domain experts and should be reflected in our code representing the domain model. In payments context, the same customer might be described just by an identifier and credit card number.īounded context has linguistic barriers (yes, language is important, even for us, geeks□). For example, customer might be described by it's name, age, username, etc. The reason for that is the fact that certain things might have different meanings. They help with maintaining the integrity of domain models within certain context, by clearly defining boundaries of model's responsibility in the code. Think about custom made ORMs.īounded Contexts lay in solution space. Or an idea that's sounds great in the beginning might turn into nightmare as well. However, if you decide to develop a generic domain in-house, it might over time turn into the core domain. Also, developing a generic subdomain in house is probably not going to bring your business the competitive advantage that the Core domain does. ![]() If your business isn't dealing with those things (because then it would be core domain), there's a high chance that it would be more pragmatic to buy an out of the box solution and integrate with it. A good example is invoicing, payments, email sending service. Because of that, the generic subdomains can be bought. The Generic Subdomains are important parts of the business processes, however, those are not unique. For example because of the time pressure or other drivers that exist in your environment. Hence, it's acceptable to do some compromise here if necessary. The thing is that there are more and less important parts of the problem that the software system will be solving. This less importance allows us, developers, to put less effort here on the quality.Īnd don't get me wrong, you shouldn't use all the anti-patterns that you know in the supportive subdomain. However, the supportive subdomains are a little bit less important than the core domain. Those subdomains are specific for the organisation and it's processes, that's why we cannot buy them. In other words, the supportive subdomains deliver functions that support proper functioning of the Core domain. The supportive word of the supportive subdomain term means that this part is supporting the Core domain. After some time spent with the initial Core domain, you might find a new one, that evolved from a supportive subdomain, for example. Keep your head open and listen to what people say. The thing worth remembering is the fact that business might change over time, and so might Core Domain. Wait, aren't all parts of the system equally important? Besides that, we should put most of the effort here and craft this part of the system very carefully. It's also something that may affect the decision whether the software is developed outside or in-house. What does it mean for us, developers? This is something that makes our business special and unique (in most cases). It's the reason for the application being created from scratch instead of being bought. It's what makes the application worth building in the first place. The Core Domain is the most important part of the business domain. Well, in DDD the subdomains are split into 3 categories: The reason for partitioning a larger domain into smaller subdomains is that it makes it easier to manage complexity, and separate the important parts of the system from the rest of it. One large problem domain can be split into multiple subdomains. I am still improving my DDD practice and knowledge. There was a time when I used to mix them up a little bit. ![]() Those terms are often used by Domain-Driven Design practitioners. This post is a summary, a note to myself about the differences of Subdomains and Bounded contexts.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |