DDD Context Mapping by example: Policy Management

DDD context mapping can be confusing without real-world examples. In this post we will model sample implementations for two scenarios using bounded context maps and learn to analyse the relationships from the maps. 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

Context mapping and analysis leads to deeper insights in the way we build our software integrations because it uncovers hidden dependencies. Note, these maps are not the same as system integration diagrams as they show business contexts and relationships – if modelling the current state, these maps then show the current state of your socio-technical landscape

Customer and interactions: Our sample stories

Customers interact with our software via web, mobile channels in a self-service context or via support centres by interacting with a Customer Support Representative. Let us consider an example of customer interaction from Insurance Domain

There are 2 contexts

1. Self-service Policy Management Context: Policy Portal where the customer can buy policy and manage his/her contact details
2. Customer Relationship Management Context: This is where the actor, our customer, calls the help desk and a CSR agent pulls their information

• 

• 

Lets us now look at these two contexts in a specific implementation, draw context maps and analyse this implementation for its merits, issues etc

Policy management from portal

In our example, there is a policy portal that imagines a web layer, an Experience Adapter, a domain service for Policy API and one for Customer API. Here are some specific implementation details from our example

1. The customer can manage their contact details which is implemented as real-time consistent via the experience layer invoking the customer domain service
2. The customer can manage their Policy. Adding new contacts on the account leads to a real-time API invocation to the backend customer system via the Customer API

How about drawing a context map for this? What are the bounded contexts and the relationships? What does it tell us?

This context map tells us the following

1. There is a “customer policy management” context (gray circle) that contains two sub-contexts and our software needs to handle these
2. All the customer policy management sub-contexts depend on the Identity management context. They consume the Identity management services in a fairly self-service manner
3. There are 2 Policy Management contexts – “my” (self-service) and “customer” (internal user)
4. Both policy management contexts directly depend on customer relationship management context- is this true though?

The #4th point above does not read correctly because we want to be able to show that the contexts read/write to the same database (CRM contacts and account table). The Customer API is a poor and leaky abstraction. We can redo the picture as

Take away: Key takeaway here is that shared kernel (SK) indicated long term collaboration. This implementation would imply some of the attributes of the policy systems leaked into the CRM table and strong-coupling in the two contexts leads to inability to change these or worse business outages as rules in the CRM world conflict with the Invoice management world!

Customer Management from CRM: Customer 360

In the next post we will see how to do Customer Management and Customer 360. Read the full post here