Domain-driven design in banking
Domain-driven design has become an industry standard these days. In the monolith era days, the decomposition was more at the module level; in the SOA era, the decomposition was more at the process level. In the microservices world where "Self-contained" is the principle for designing and developing the microservices domain, driven development brings significant importance.
Most of the time, designers and developers are struck at defining how much functionality needs to be included in a microservice to qualify it as a self-contained service; this is the sweet spot for microservices.
In the Banking industry, BIAN (Banking Industry Architecture Network) is gaining a reputation for decomposing the service through a domain-driven approach. BIAN provides a standard sub-domain definition.
APIs may be identified using Domain Driven Design
- Aggregates and Entities become Resource APIs
- Value Objects inform the design of the resource APIs
- Services become Process APIs
In banking, there are short-running business transactions like payments, remittances, funds transfers, etc., and long-running stateful processes such as customer onboarding, mortgage origination, etc.
First, Let's take a transaction type such as "management of balance" for an account per BIAN standard. The following diagrams provide a perspective on how to perform domain-driven design for managing accounts.
Now, let's look at a similar example of the long-running process of domain decomposition. The following diagram explains how the decomposition is performed for a mortgage origination process:
The above two examples would have provided a brief view of how domain decomposition works for BIAN. BIAN goes even further than domain decomposition and provides process definition for common event scenarios like origination, funds transfer, etc, and the Symantec swagger definition for the services in the banking domain.
