In the continuation from the previous post, here we look at how to do context mapping from sample real-world examples. In this post we look at how to model Customer Management from a customer support perspective and how Customer 360 would look like as a context map
With this post, I hope to give you a fair idea of how to do apply DDD into build good distributed features and integrations using strategic and tactical design patterns
Domain Storytelling
The customer management Domain Story should look familiar. The key thing to ask is how the customer related information gets to the CRM system to build a 360 view and what is stored in the CRM system
One anti-pattern is to store the rest of the enterprise information model into our CRM to build a giant monolithic database with data syncs. This should lead to the right pattern question then, “how do we get the relation information? what is the right pattern?”
Context Mapping
The simplest context map of the to-be state then would be the following
This shows that the CRM context depends on the other contexts via open-host services (OHS) and implements an anti-corruption layer (ACL) when invoking the services or receiving events.
Note: The picture does not say anything specific about the implementation (events or APIs, what data etc) because this is part of “strategic” DDD
Tactical DDD: Service Design
Now that we know how we want to interact across the bounded contexts, we use the ubiquitous language of the customer management context and, say, policy management context to find the “model”. This means creating the domain aggregates, value objects and entities then look at the state change events etc
For example, we can imagine the Customer Management context for 360 view cares about all the related contexts, then it needs to consume their domain events and query the APIs. A sample is shown below
Summary
In this series we looked at how to apply DDD context mapping at a real-world use case in a couple of contexts. We then implemented a service model based (without going too deep into tactical DDD)
The key thing to examine above is to look at the bounded contexts, relationships and the proposed implementation via the services and events. Hope this gives you a fair idea of how to do apply DDD into build good distributed features and integrations
Alok Mishra 