I have started work on a new project where we are architecting and building a new digital retail bank from scratch. To architect a bank from scratch is a huge undertaking. There are many systems and partners involved. I have only started working in the banking domain from the last one year and I can surely say the banking domain is full of interesting technical challenges. Both incumbent and challenger banks are building systems using cloud native architecture and technologies. It is an interesting time to be working in the BFSI and FinTech space. Digital banks open up a possibility of making banking possible and accessible to millions of people across the world.
Shameless plug: I am hiring. If you are a software engineer or an architect looking for interesting technical work then contact me using the contact form.
DDD stands for Domain-driven design. This term was coined and popularized by Eric Evans when he wrote the seminal DDD blue book[1] in 2003. I read the blue book 7 years back. It made me understand why it is important to have a good understanding of the domain when building complex software.
In the last 7 years I have applied DDD and its patterns to build and architect multiple systems. It has helped me guide my discussions with the business folks and help me create a shared understanding on the business problem at hand.
In the last five years with Microservices being at the centre stage of all digital transformation efforts there is a renewed interest in DDD. Domain-driven design provides a set of strategic and tactical design tools that can guide us to come up with the right functional service boundaries and build better Microservices. If you are using Microservices then I am sure you would have read that we should use DDD strategic tools to identify Microservices. Microservices should be extracted based on the business capabilities. There should be one Microservice per bounded context.
In this series on DDD we will demystify DDD by applying it to a real domain so that we can learn how it can help us in architecting systems. This is going to be a learning experience for me as well. I am writing this series as I apply DDD at work. I might make mistakes so please reach out to me via comment section or contact form.
In this post I will cover how Subdomains, DDD strategic design pattern, can help you analyze and understand the banking domain.
A retail bank is a big domain that is composed of multiple fine-grained problem domains. These fine grained problem domains are called Subdomains. A subdomain provides solutions for specific business capabilities.
DDD suggests there are three subdomains – Core, Supporting, and Generic
A core subdomain:
- Has competitive business advantage for the bank
- Has high complexity
- Should be custom developed
A supporting subdomain:
- Has limited competitive business advantage for the bank
- Has low complexity
- Should be custom developed
A generic subdomain:
- Has no competitive advantage for the bank
- Is already solved
- Has high complexity
- Should be bought or adopted (open source solution)
We will use a simplified version of Core Domain Charts[3] to help us visualize different subdomains.
The above core domain chart helps you understand the business strategy of the bank.
The core subdomains listed in the diagram above help us understand that the bank plans to bring innovation in the core banking products like CASA and deposits. Data will play a big role in the features the bank wants to provide via personalization and recommendation subdomains. Search is core to the bank since they want to build a universal search that can search across your beneficiaries, transactions, menu options, etc. All the core subdomains will be custom developed to have the business differentiation.
In the diagram above I have not shown the Y axis. The Y Axis plots complexity. It is not easy to define complexity. You will have to understand the essential complexity of the domain. Essential complexity could be due to the difficult conceptual model, or difficult processes, or calculations, or some combination of all of them.
It is important to note that subdomains can change their type. A core subdomain today can become a supporting or generic domain tomorrow. It can happen in the other direction as well. You might start with a SaaS offer management system but later it can become core to your business and you will develop a custom solution that is unique to your problem domain. Then, offer management solution will become core subdomain.
We can extend the core domain chart by adding an experimental sub-section in the core domain. Let’s assume that a bank wants to offer PFM(Personal Finance Manager) as part of their application. To build a PFM you have to analyze and categorize transactions so that you can give meaningful recommendations and analysis. Bank can run a timeboxed experiment and if the experiment is successful then it can become a subdomain in the core domain charts. Experiments are bets for the future. They may or may not yield desired results but a learning organization will always find value in the failed experiments.
That’s it for today’s post. In the next post, we will talk about bounded contexts.
Shekhar Gulati 