![]() ![]() Sometimes it’s relatively easy to split a business domain into various subdomains, each representing a bounded context to render with software.īut is it splitting or is it partitioning? There is a huge difference between the two. There are two additional aspects vital to investigate: the boundaries of each bounded context and their relationships. In the current draft of the top-level architecture, we have two candidate bounded contexts. This probably makes for another subdomain. Is it the only one? Most likely, the system needs a back-office panel to put content on the site and perhaps extract statistics. The front-end web site is certainly a subdomain. Without flying too high conceptually, consider a simple booking system. Likewise, a subdomain is a segment of the domain, and a bounded context is a segment of the solution. The domain represents the problem to solve the domain model is the model that implements the solution to the problem. However, both concepts can be easily understood by looking at the difference between a domain and domain model, which is probably easier to grasp. Subdomains and bounded contexts are concepts that sometimes appear to be similar and can be confusing. A bounded context can have relationships to other bounded contexts. Or, put another way, a bounded context is a boundary within which the ubiquitous language is consistent. In DDD, a subdomain in the problem space is mapped to a bounded context in the solution space.Ī bounded context is an area of the application that requires its own ubiquitous language and its own architecture. This probably means that the business domain you assumed to be one and indivisible is, in reality, articulated in subdomains. ![]() When this happens, you probably crossed the invisible boundaries of a subdomain. As you proceed, you learn how the organization works, which processes are performed, how data is used and, last but not least, you learn how things are referred to.Įspecially in a large organization, the same term often has different meanings when used by different people, or different terms are used to mean the same thing. In the beginning, you assume one indivisible business domain and start processing requirements to learn as much as possible about it and build the ubiquitous language. ![]()
0 Comments
Leave a Reply. |