This is the second in a series of posts looking at the similarities between Sitecore Helix and Domain Driven Design. This time I'll focus on the DDD concept of Bounded Contexts and how understanding them can deepen your appreciation of Helix.
In the past, organisations creating software systems usually attempted to form a single unified model of their entire business. They often failed because the model ended up being too unwieldy and full of contradictions. Any organisation of sufficient size and complexity will have numerous areas, each with different interests and aims. There is no single model that will satisfy them all equally.
DDD attempts to deal with this problem by breaking down a large, complex domain into smaller 'subdomains' (these might correspond to departments or some other cohesive sections of the business). Modelling subdomains independently makes the problem simpler to reason about. Those small models are called 'Bounded Contexts'.
In my previous post I introduced 'Ubiquitous Language', where a development team works with domain experts to find a consensus on the terminology to use when describing a model. An important point is that a ubiquitous language is only consistent within a single bounded context. Each team/department will have their own internally consistent ubiquitous language. It might have things in common with another bounded context, but it will also have significant differences.
The diagram below demonstrates an extremely simplified example of 2 bounded contexts within a system. Notice that both contexts have a shared concept, but assign it different names ('Product' and 'Unit), It's likely that each context will have it's own understanding of that concept, and will be interested in different aspects of it.
Each bounded context also has concepts that aren't shared with the other.
Here's the good bit. In DDD, we're encouraged to pay close attention to the discrepancies in an organisation's language, because they often reveal a context boundary. Imagine having a conversation with a group of domain experts where some use the word 'Product' and others use the word 'Unit', even when their talking about the same object. That should get your DDD senses tingling.
I think we can do the same thing in a Helix project. Look for those differences in terminology and they might just help you discover a new set of feature modules.
If you have any other ideas about applying ideas from DDD bounded contexts to Helix, please leave a comment.
In the next post in this series I'll look at what DDD has to say about the different kinds of relationship between bounded contexts, and what that can teach Helix developers.
DDD attempts to deal with this problem by breaking down a large, complex domain into smaller 'subdomains' (these might correspond to departments or some other cohesive sections of the business). Modelling subdomains independently makes the problem simpler to reason about. Those small models are called 'Bounded Contexts'.
In my previous post I introduced 'Ubiquitous Language', where a development team works with domain experts to find a consensus on the terminology to use when describing a model. An important point is that a ubiquitous language is only consistent within a single bounded context. Each team/department will have their own internally consistent ubiquitous language. It might have things in common with another bounded context, but it will also have significant differences.
The diagram below demonstrates an extremely simplified example of 2 bounded contexts within a system. Notice that both contexts have a shared concept, but assign it different names ('Product' and 'Unit), It's likely that each context will have it's own understanding of that concept, and will be interested in different aspects of it.
Each bounded context also has concepts that aren't shared with the other.
What does all this have to do with Helix?
I don't think it's too much of a stretch to make a link between bounded contexts to Helix features. Not all features are focused on the core business domain, but I think the ones that do, share a lot of the same properties.Here's the good bit. In DDD, we're encouraged to pay close attention to the discrepancies in an organisation's language, because they often reveal a context boundary. Imagine having a conversation with a group of domain experts where some use the word 'Product' and others use the word 'Unit', even when their talking about the same object. That should get your DDD senses tingling.
I think we can do the same thing in a Helix project. Look for those differences in terminology and they might just help you discover a new set of feature modules.
If you have any other ideas about applying ideas from DDD bounded contexts to Helix, please leave a comment.
In the next post in this series I'll look at what DDD has to say about the different kinds of relationship between bounded contexts, and what that can teach Helix developers.
Comments
Post a Comment