Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
There’s one key aspect that can really unlock your understanding of domain-driven design: the ubiquitous language. It’s the secret sauce. Let’s explore some different ways of thinking about it that might just give you the big “aha moment” you’re looking for.
YouTube
Check out my YouTube channel, where I post all kinds of content accompanying my posts, including this video showing everything in this post.
Be Aware of Terminology
First, be acutely aware of the terminology and words used in any part of the organization. Words have different meanings depending on the context, and recognizing this can help you identify boundaries within your domain.
For instance, if we take the transportation domain, the same term might mean different things to people in different departments. When you talk to someone in compliance about a truck, their concerns will revolve around compliance and insurance.
In contrast, if you speak to someone in operations, they’ll be focused on its location and shipment status.
This illustrates how essential it is to understand the language being used and how it applies within the specific context. This awareness is the foundation of forming your ubiquitous language.
Concepts and Policies
Next, be aware of concepts beyond just entities and value objects. Business rules and processes often have concrete names that you need to capture. If you’re dealing with conditions, consider that they might represent policies.
Document these concepts clearly in your ubiquitous language, which will help you translate between business and technical terms.
For example, when dealing with transportation, knowing that Dispatching is a command and that an Order Dispatched is an event makes it easier to navigate the codebase because your technical language mirrors the business terminology.
Understanding Multiple Contexts
Another tip is to be careful about speaking with individuals wearing many hats. In a small or large organization, someone with a broad overview can shift contexts quickly, which can be confusing.
They know the domain often so well that they can talk about many different aspects of different contexts. To them it’s not confusing at all, but to someone with much less understanding, it can be difficult to understand when they are switching.
It’s like walking into a dark room with only a flashlight—you need to shine it around to get the lay of the land. This is where event storming can be beneficial, as they help build out your ubiquitous language and bounded contexts.
Legacy Systems and Discovery
Be cautious of legacy systems that might guide you down the wrong path. Sometimes, the terminology you’re using may stem from outdated systems rather than what you want to move toward.
When building your ubiquitous language and defining boundaries, consider whether you’re working on a project or a product. For instance, if you’re a SaaS provider, your clients might be in the same domain but operate slightly differently—this is where their competitive advantage lies. They might also use different terms for similar concepts.
Understanding these nuances is important on how you want to define your ubiquitous language.
Maintain Synchronization
As you define your language, it’s important to try and keep them in sync with your actual code. Your code should reflect the ubiquitous language you’ve agreed upon. This means constantly paying attention to the terminology in use and ensuring that it evolves alongside your project.
The aim is to avoid having a disconnect between what’s in the code and what’s being discussed in the business context.
If your code structure reflects the language being used within the context, it will be much easier for everyone to understand and collaborate.
Final Thoughts
Hopefully, this discussion has sparked some insights into how you approach language in your projects. The ubiquitous language is not just a concept; it’s a strategic element of domain-driven design that can bridge the gap between business needs and technical implementation. I’d love to hear your thoughts on this. What are your big “aha moments”? How do you think about language in your projects? Share your experiences in the comments.
Join CodeOpinon!
Developer-level members of my Patreon or YouTube channel get access to a private Discord server to chat with other developers about Software Architecture and Design and access to source code for any working demo application I post on my blog or YouTube. Check out my Patreon or YouTube Membership for more info.