Overview

In the introductory blog post, we took a look at how BFSI enterprises could approach their technical and organisational structures with a domain focus. One of the topics we touched upon was around Domains & DDD, Structures, and how enterprise scale companies would be better served by a Product mindset. In this post we will delve deeper into this topic, and deconstruct the components and entities that comprise the organisation. For the rest of this post, we’ll be using the example of a bank. However, the concepts we cover could apply to any organisation that serves its users across a range of domains and subdomains.

‍

Deconstructing the underlying structures

The diagrams below are simplified and serve to illustrate the concepts I’m talking about. They are not meant to be an exhaustive breakdown of the real-world systems and processes involved.

Channels

Now, let us think of a bank. A typical bank normally serves its customers through physical or digital means.

Online and Digital: They could serve customers online through their mobile and web apps. They could also serve partners and third party fintech applications etc online through their APIs. They could have different digital interfaces that cater to retail customers, SMBs, and Enterprise customers. They could have layers of B2B interfaces that abstract from the end users.

Physical: They could serve customers through the bank’s branches, through ATMs, through the bank or 3rd party agents who work directly with customers, etc. Each of these physical interfaces could have a host of applications that allow them to connect to the bank’s systems.

We collectively refer to these interfaces as Channels.

‍

For the sake of simplicity, for the rest of this post, let us focus on Digital Banking, and view the sections below from that point of view.

User Facing Products and Journeys

Banks normally serve a host of products to their customers. These include core banking products: Different types of Accounts, Loans, Transactions, Payments & Transfers etc. Most medium and large banks also provide products like Credit Cards, Deposits, Investment Banking, Wealth Management etc.

All of these products comprise of different customer journeys (opening an account, making a transfer, setting credit limits, registering a payee, withdrawing cash etc). Different combinations of customer categories and products will have their own sets of user journeys. And they could be serving the customers or end users via various channels. The diagram below is a simplified illustration of what some user journeys might look like, and the user steps involved.

‍

Journey Workflows

For each step of these user journeys, there could be a whole series of workflows that happen in the bank, which are completely abstracted away from the users. These are a sequence of steps the bank needs to do in order to fulfil the customer journey requirements.

‍

Subdomains & Capabilities

From the overall domain of banking, we can break it down to a set of sub-domains, based on  certain categorisation criteria. One good way to map out sub-domains is along the lines of the set of capabilities they serve either to customers or to other systems within the bank.

The user facing products mentioned above could fall into a series of subdomains, for example:

• Accounts
• Loans and Finance
• Credit Cards
• Payments and Transfers
• Customer Management

All of the above could be thought of as Primary Subdomains. These have capabilities that are served directly in User Products and Journeys.

You could also have subdomains that handle shared needs across products, and serve capabilities that are consumed by the Primary Subdomain services in order to fulfil their user journeys and bank workflows, for example:

• Digital Identity
• Customer Engagement
• Fraud and Risk Mitigation
• Security

In Domain Driven Design (DDD) for Software Development, we have the concept of “Bounded Contexts”. We will dive into DDD in more detail in the next post. But for this post, those of you who’ve read up on DDD could see some of these subdomains mapping neatly to Bounded Contexts

‍

In the image above we have some examples of how the subdomains could be broken down, and the ovals inside the subdomain represent the capabilities served in that subdomain.

‍

Horizontal and Vertical : Mapping Journeys and Workstreams to Subdomains and Capabilities

If we consider the customer facing products and their inherent user journeys and workflows as a “Horizontal” sequence of events.

Each step in that horizontal sequence is fulfilled by “Vertical” blocks: the subdomains serving various capabilities. The primary subdomains directly serve capabilities to the journey, while the supporting subdomains provide capabilities to the primary subdomains.

The above is a simplified diagram showing some of the relationships between the subdomains and the workstreams. So we can think of the services that make up each of the subdomains above as a “Platform” serving the capabilities of that subdomain. So we effectively have horizontal journeys & workstreams on top, and layers of vertical stacks of domain aligned platforms serving capabilities to the horizontal journeys.

What’s next?

All of these examples above are simplified to illustrate the high level concepts of breaking down the underlying structures in an example bank. We didn’t delve into the details of mapping workflow steps to capabilities at a granular level etc. In the next post, we’ll dive deeper into the topic of Domain Driven Design (DDD), and explore creating an actual domain model, and DDD concepts and terminologies like Bounded Context, Domain Events, Entities, Services, Aggregates, Factories, Value Objects, Repositories etc. We will also look at techniques like Event Storming in order to break down and create the domain model for any domain. With that, it’ll allow us to make a fine grained mapping of Journeys, Workflows, Subdomains, and Capabilities.

‍

‍