DDD Context Mapping By Example: Customer Management and Customer 360

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

Customer 360 context map: DDD perspective

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

Sample implementation across two contexts using tactical DDD


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

Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s