Our sample application is a risk engine, which mostly have some rules. Based on the data we have, we run a rule on it and try to find out a score. On the basis of that, we will find out how much risk is involved in lending money to a particular user. We will try to conceptualize what a risk engine component is, define a database, and use some DDD on those to come up with a microservices-based data model.

A risk engine has to have user details. Users have many details, as shown in the following diagram. Users can have much more data, but we are showing this as a sample application to make you understand how we should think in terms of domain:

If we look at the preceding data model example, we can see that all the information is related to a user. The question is, does all the information come in one domain? Or can we figure out different domains in these data attributes?

We can see four domains or segments in that information. We divided these domains or segments based on data which seems to be related and normally changed together. The following diagram shows the domains we can identify:

Dividing the domains fairly depends on knowledge and expertise. Let's explore these domains and understand why we chose them.

Domain -1 (Details)

It basically deals with user details. The minimum information required to register a user. It needs name, gender, date of birth, unique ID, and address. We put these in the same domain because the probability of changing this data at the same time is high. Updating this data should not affect the other data models. If someone updates the user's address, it should not affect the bank account number, income, and so on.

Domain 2 (Financial)

Domain 2 mainly consists of financial information. It could be bank details that the user is using, and also the income of the user. Both types of information are somewhat related. For example, if a user is a salaried employee and they change their job, there is a high probability of changing the income and also the bank account. As some companies open salary bank accounts in their collaborated banks, that makes the probability of having a new bank account with a change in job very high.

A new company may ask a user to create a new bank account in their collaborated banks. That's why we have this information together. One interesting thing here is a change in employer can change the user address also. So, should we add the address here? It mainly depends on past experience and the dataset we have for the target user. That's where domain experts come into the picture. One could think in a way that people with a lo of experience or a wide skill set must have purchased a house and have a family. These kind of users do not change their address very frequently. So, you have to identity the dataset and try to find a pattern in the data that changes together.

For our application's risk engine, we are assuming we will be giving a high bucket loan. A high bucket loan is a risk that can be taken only if users have a high income and also the chances are that the users have purchased houses already. So, there are less chances that the address of users change frequently. So, keeping this probability in mind, we are not keeping addresses with income. There should be the right balance between domain and data set pattern knowledge to make this work.

Domain 3 (Authentication)

Domain 3 is a simple domain for authentication. The application should have a unique way of authorizing and authenticating the user. That's why credential information is put together as a different domain.

Domain 4 (Communication)

Domain 4 is more to deal with channels from where the application communicates with users. In the preceding data model, we can see the phone number and email are used to communicate with users and both of them fit in the communication domain. If we have a mobile app or want to store the device IDs of those, we can do it here.

Now we can think of moving them to storage. In our use case, all can go to a relational database. We can have different databases for each domain and can have tables to store data. Domains will be connected by user IDs. Whenever a new user registers, their information will be published with a create event and user ID. All other services will be subscribed to events. After listening to the event, they can make entries in their database also. Generations of user IDs can be the responsibility of the first component. It will be used by all other components.

This is one way we can start modeling of our application. You may have gotten an idea about how to start thinking in terms of domains and datasets, rather than a relational model or storage unit first.