To me this has a very antiquated feel about it.
#Define domainer software
Some people suggest that subdomains are part of the problem space an chosen by “The Business” whereas bounded contexts are software boundaries defined engineers. Perhaps the most confusing and controversial topic of all is subdomains vs bounded contexts. It’s fuzzy but not ambiguous.Ĭore Domain sounds better, Core Subdomain emphasises that there is a higher-level domain to which this belongs. When you view domains and subdomains as fuzzy, and subdomains also as domains, using core domain and core subdomain interchangeably doesn’t really matter. In his DDD books, Eric Evans refers to them as Core Domains, but he also refers to them as subdomains. People are often confused when they hear that a core domain is actually a subdomain. The only time I wouldn’t say a domain is also a subdomain is when our model does not contain a higher-level parent domain. When we use the word subdomain, we are emphasising that the domain we are talking about is a child of another higher-level domain which we have identified.Įvery subdomain is, therefore, a domain, and most domains are a subdomain. Domain and subdomain can be used interchangeably. The word subdomain is used prominently in the world of web hosting, but what does it mean in DDD? What’s the difference between a domain and a subdomain? This one is easy - subdomain is not a word that exists in the dictionary.
This is normal, embrace the fuzziness and apply design thinking. Even if we align we align by ‘colour’ the shape domain is still a domain that exists.Įvery domain I model and every modelling workshop I run, different people like to slice up systems across different domain boundaries. When modelling systems we have to choose the most appropriate domain boundaries with which to align our software and organisational boundaries. The same concepts can belong to different domains We think we’re talking about the same thing but we’re not. If I say a word and I expect that you have the same definition, but you actually have a very different definition, we have false alignment. The key thing is that the fuzziness should be easily inferred from context (if different people interpret it in significantly different ways, that’s too ambiguous). In others it can mean £100s of pounds “can you lend me a few quid?”. In some scenarios it might imply a low range like 2 - 3 and in others it could imply a different range like 5–10.
By having fuzziness in DDD, we can explore, model and solve new and novel problems because the existing patterns and principles don’t over-constrain our thinking.īy fuzzy I mean that a word can be used to describe different things that are similar in some way but not identical. Fuzzy But Not Ambiguousīefore defining each term, I want to emphasise an important point that Kenny Baas-Schwegler makes. This post is based on a long conversation on github involving many people from the DDD community. At that time IT was a separate department from “the business”. It’s also worth keeping in mind that DDD was published in 2004 at a time when empowered, cross-functional product teams were rare. In this article, I’m going to provide working definitions of those concepts and clear them up. Everybody has their own definition of Domain, Subdomain, Problem Space and Solution space. However, some concepts in DDD do not have a clear definition and are highly implicit. I would also highly recommend Why I Don’t Need a Bounded Context by Herman Peeren. If you like this article, you may like another article I’ve written: What is a Domain? Famous DDD principles include Use a Ubiquitous Language and Make The Implicit Explicit. Domain-Driven Design is an approach to designing systems, usually software, that emphasises creating a common language between domain experts and system builders.
0 kommentar(er)
