How Domain-Driven Design Can Improve Collaboration
How to reduce complexity and improve internal communication using DDD concepts
How to reduce complexity and improve internal communication using DDD concepts
Key Takeaways
Domain-driven design is n approach to software development focusing on modeling domains and business logic.
Two main concepts that can be used widely to improve communication are the ubiquitous language and the bounded context.
Improve collaboration by identifying areas you work in, their unique language, and clarifying the terminology used in each.
Overview
To quote Martin Fowler –
“Domain-Driven Design (DDD) is an approach to software development that centers the development on programming a domain model that has a rich understanding of the processes and rules of a domain. The name comes from a 2003 book by Eric Evans that describes the approach through a catalog of patterns.” — DomainDrivenDesign
I’ve read Evans’s book as a non-engineer and found some great lessons about communication and tackling complexity in product companies.
I will share two main DDD concepts and how to apply them in life. While these concepts are technical and refer to software engineering, I use them loosely to explain real-life concepts in a product company.
It All Starts With Language
Let’s imagine for a minute your company is a Domain, and your department or team is the Subdomain. Now, there are probably terms used widely within the domain like “user,” “goal,” “conversion,” or “revenue.”
However, in each Subdomain, words might have different meanings — for example, for finance, the term “account” might mean a bucket in the journal, while for the support, it means a user in the product. I will refer to Subdomain as Area for a more straightforward explanation.
Have you noticed that we already have four words with ambiguous meanings in a simple sentence? That’s where the complexity starts and where the ubiquitous language comes in.
A central concept introduced in DDD is using the same language everywhere — in conversations, documentation, and the code. Technical experts (engineers) and Domain experts should use the same language.
And It Follows With Context
Now, let’s return to the example above. Let’s say I’m working in a Growth Marketing team, and this is my area. I work closely with other teams such as Acquisition, Digital Marketing, Brand Management, and more. We all work within the Marketing context.
For that reason, DDD introduced the concept of Bounded Context. Within each Bounded Context (Marketing in our example), we have a unique language. We understand each other. If a Marketing Manager talks about SQL with an Engineering Manager, he risks not being interpreted correctly.
To solve it, we must define the context (e.g., Marketing), the area (e.g., Growth Marketing), and the language we use.
Acknowledge And Adapt
To wrap it up, we need to acknowledge our areas, context, and language and adapt ourselves when talking to others. What does it mean?
You have a unique language — while terms like “account” or “user” sound evident to you, they are not! Most definitely when talking to colleagues from other areas or contexts.
Be persistent — ambiguity in our language, or the usage of different words for the same purpose, make it complicated to understand us.
Adapt your language — when talking to others, clarify the terms you are referring to, and make sure the context is clear. Sometimes, you might need adapters, such as agreeing on a particular terminology when communicating externally.
When working with product teams and engineers, consider writing a glossary to reduce ambiguity.
Final Tips
Language is the foundation of communication, and to succeed, we need excellent communication.
After you acknowledge your area and are aware of your language, try the following tips when engaging with other areas –
Clarify The Context
It may sound obvious, but make sure the context and areas are clear. For example, in a discussion about products, you can ask, “are we talking about products from a marketing point of view?”
Clarifying the context will help understand the hidden language and motivations.
Clarify The Terms
Don’t be shy to ask something like, “when you say the word ‘account,’ what do you mean? Is it the same as ‘user’?”. When working on a project, use agreed-on terms and provide a glossary summarizing them.
Be The Champion
With your new knowledge, you can reduce complexity and improve communication. Ask the right questions and use precise terminology.