Thursday, November 3, 2016

Ubiquitous Language and Context Maps in Domain Driven Design

In today's blog post, I will be covering a few more key terms in Domain Driven Design. We will be discussing Ubiquitous Language and Context Maps. This is is continuation with last week's blog post about Domain, Sub-Domain and Bounded Context which we discussed here.

Ubiquitous Language

Some people call it the language of the business. Some people call it the language of domain experts. In reality, it is a language shared by the team i.e. domain experts and developers alike. The domain experts do have a high influence on the language but they don't decide everything. It's dependent on how the business thinks and operates. If you have multiple domain experts on the same team, they themselves might have different terminologies. So the domain experts and other team members all need to be on the same page.
Also, there might be scenarios which the domain experts have not even considered. Developers and QAs s are good at finding such scenarios ;) In such cases, the language & terminologies might not even exist and the team might have to come up with some new terms. All these become part of the ubiquitous language.
Lastly, it's not a one-time thing. It grows and changes over time. As the understanding of the domain improves for domain experts and other team members, new terms are added and existing terms are updated with time.

Ubiquitous Language and Context Maps in DDD

Context Maps

A context map can capture the technical and organizational relationships between various bounded contexts. It shows the boundaries of the bounded contexts and the contact points of these contexts among each other.
Also, it shows how various bounded contexts communicate with each other and what type of relationships exist among them. It represents the holistic view of the application. This is helpful in informing the teams their own communication points and how they can communicate with other teams.
A context map need to be updated whenever there is any change in the boundaries of the bounded contexts or change in how they talk to each other.


Conclusion

So we defined some more key terms in the Domain Driven Design this week. We will be continuing with our journey by learning more about context maps and what it contains next week.


References:
i)  Domain Driven Design By Eric Evans;
ii) Patterns Principles and Practices of Domain Driven Design By Scott Millet

No comments:

Post a Comment