Modelling the domain-Citing Example

We will take an example of banking domain. Most of the times, when you start with the DDD modelling, you will not be clear about the boundaries up-front. But when you have a huge domain like Banking, with a good clarity on requirements, it’s always good to start with identification of sub-domains.

Isolation reduces the complexity within the business

To start with an simple example, the business wants to kickstart by launching a Credit Card in the market. It’s a proven thing that the businesses today are more agile and the market dynamics change more often than it was in the past 20 years. So your model should support changes at minimalistic cost.

To go with the DDD way, we must try to identify the sub-domains here which are/or would be large enough to be given an isolation. Most often and not always , it’s the way business team has aligned or formed departments to handle each section gives a hint of forming sub-domains.

In areas where you think,the business is too naive, it would be better to go with a monolithic approach and then gradually identify the boundaries of each your services to be classified as a sub-domain.

Typically in our use-case based on public domain information on Credit Card, we have identified basic sub-domains

  1. Acquisitions (for handling the application process,identifying potential customers)
  2. Customers(Handling all customer related information. e: Updating name)
  3. Accounts(Handling all the monetary aspects)

It’s a good point to start with these domains, and start organising your requirements in each of these buckets.

organising your requirements in different sub domains.

It’s important to understand the bounded contexts of each sub-domain. e.g: name model is in the bounded context of both acquisitions and customers, but each one of them should be treated differently in it’s own context. The advantage of treating them in their bounded context is the changes in name model of customers should in no way affect Acquisitions.

Context Mapping is another important terminology in DDD. It’s always better to have an uniform naming convention throughout your domain. But sometimes it’s not feasible in context of some sub domain. eg: Let’s say you have another sub-domain called communication, which has a different concept of Address(it refers it to email address), whereas your Customer domain calls it as customer’s postal address. Here’s where the context mapping comes to map customer’s address to communication’s contact information model. Usually this layer which does that mapping is filtering layer of that sub-domain, which simply does the mapping. It’s also important to have a good document depicting these context mapping between different sub-domains, for business team to get the understanding of flow at the high level.

You evolve your domain by identifying more sub domains based on your business flows.