This is the first in a series of posts in which I explore the parallels between the Sitecore Helix architecture and Domain Driven Design (DDD). I think Helix has been heavily influenced by DDD, and a good place to start is to introduce its concept of 'Ubiquitous Language'.
The Helix documentation website has an entire section dedicated domain language and the importance it has to the architectural principles. It recognises that communication issues arising from using incorrect terminology are a major source of problems within software projects. So it stresses that developers should learn to speak the language of domain experts. Team's are encouraged to continually refine their common language to eliminate ambiguities.
I think that's a sensible approach, but I suspect that most developers who read the Helix documentation disregard the Domain Language section - it's probably just one of the 'fluffy' soft skills that managers are so keen on.
But DDD emphasises that paying close attention to language is massively beneficial in forming a robust, effective conceptual model of a system. In fact, Ubiquitous Language is central to the DDD philosophy. Martin Fowler describes it as:
Having a ubiquitous language makes it easier to reason about business logic. You can discuss the concepts that exist in your codebase with domain experts without needing any translation. If you discover ambiguities in their language, then you can work together to refine it.
Ultimately, I would argue that establishing a ubiquitous language is useful to any software project, not just one that follows Helix or DDD. But but there are specific benefits to Helix too. In my next post I'll introduce another DDD concept - the Bounded Context. Then we'll see how a ubiquitous language can offer important insights in to your Helix solution.
The Helix documentation website has an entire section dedicated domain language and the importance it has to the architectural principles. It recognises that communication issues arising from using incorrect terminology are a major source of problems within software projects. So it stresses that developers should learn to speak the language of domain experts. Team's are encouraged to continually refine their common language to eliminate ambiguities.I think that's a sensible approach, but I suspect that most developers who read the Helix documentation disregard the Domain Language section - it's probably just one of the 'fluffy' soft skills that managers are so keen on.
But DDD emphasises that paying close attention to language is massively beneficial in forming a robust, effective conceptual model of a system. In fact, Ubiquitous Language is central to the DDD philosophy. Martin Fowler describes it as:
"a common, rigorous language between developers and users. This language should be based on the Domain Model used in the software - hence the need for it to be rigorous, since software doesn't cope well with ambiguity."How many times have you worked on a Sitecore solution that uses ambiguous terminology? Just last week I refactored some legacy code that used the terms 'Site Root', 'Country' and 'Sub-Region' interchangeably. The domain experts in this case would recognise all of these concepts. But for them, the individual meanings are slightly different. Each have nuances that an uninformed developer might not understand.
Having a ubiquitous language makes it easier to reason about business logic. You can discuss the concepts that exist in your codebase with domain experts without needing any translation. If you discover ambiguities in their language, then you can work together to refine it.
Ultimately, I would argue that establishing a ubiquitous language is useful to any software project, not just one that follows Helix or DDD. But but there are specific benefits to Helix too. In my next post I'll introduce another DDD concept - the Bounded Context. Then we'll see how a ubiquitous language can offer important insights in to your Helix solution.
Comments
Post a Comment