How to start your journey into Microservices Part -2 (DDD)

In the last blog we learned that there are various areas of designing microservices.

In this blog we will work on decomposition of a larger problem into smaller microservices and look at the subtle but very important aspects on why to breakup and how simple it could be.

For this we will be using DDD. We will not go in detail of what exactly is ddd , we will work on the strategic design part of DDD, but lets still iterate over some of the principles of DDD.

One principle behind DDD is to bridge the gap between domain experts and developers by using the same language to create the same understanding. You must have seen cases where it becomes difficult for the product managers / experts to iteratively add features as the language between the pm and dev is different.

Another principle is to reduce complexity by applying object oriented design and design patters to avoid reinventing the wheel.

But what is a Domain? A Domain is a “sphere of knowledge”, for instance the business the company runs. A Domain is also called a “problem space”, so the problem for which we have to design a solution.

Lets choose a business problem like building a E-Commerce site<Amazon> on which we will try to apply DDD. We will not be able to go in complete depth of the business problem. I am writing very basic features required for it to work:

1. User searches for a product
2. User place a order for that product
3. User pays online
4. Delivery Management processes that order and start the delivery
5. Delivery update the Order Status

Now we will try to design this in traditional way, lets create the schema:

• Tables
  • Product
    • id
    • name
    • image url
    • price
    • count available
    • ….
  • Product Packaging Info
    • id
    • product id
    • size
    • isFragile
    • …..
  • Order
    • product id
    • user id
    • delivery address details
    • paid
  • Order Delivery Status
    • id
    • order id
    • delivery company name
    • delivery company id
    • delivery company code
  • Delivery Company
    • id
    • name
    • ….
  • User
    • id
    • name
    • address details
  • User Preferences
    • id
    • name
    • preferences

We can create a table structure like this in our system<lot more tables will be there>. I think by looking at those tables you could understand not all tables to be understood by every dev, eg: someone working on delivery management might not be interested in UserPreferences <used for searching> and someone working on searching might not be interested in OrderDeliveryStatus.

By this you can understand that we need to break the structure in smaller areas.

To design this in a way which helps to put more business context and smaller structure to manage . Lets put DDD.

As Domain in DDD means we are talking about a specific set of area <knowledge> . In larger sense E-commerce domain can be classified internally by various subdomain like:

1. Identity Management
   1. User
2. Inventory Management
   1. Product
3. Product Search
   1. Product
   2. UserPreferences
4. Order
   1. Order
   2. Order Delivery Status
5. Delivery Management
   1. Order
   2. Product Packaging Info
   3. Delivery Company
   4. Order Deliver Status
6. Billing

The separated Domain can easily be visualized. In DDD terms this is called a Context Map, and it is the starting point for any further modeling.Essentially what we have done is breakup the larger problem into smaller interconnected ones.

Now we need to align the Subdomain aka problem space to our solution design, we need to form a solution space. A solution space in DDD lingo is also called a Bounded Context, and it is the best to align one problem space/Subdomain with one solution space/Bounded Context.

In this we can think of each sub domain as a diff. microservice. Microservices are not complete without their dependencies . lets see them in context of bounded context:

• Product Search – dependent on – Inventory Management
• Delivery Management – dependent on – Order
• Product Search – dependent on – User
• Billing – dependent on – order
• … so on

you can see that their is dependency between order and billing service and they talk via a common shared objects model which both of them can represent separately rather that using a single complete model which is cumbersome eg: order object in order service<care about status> is different from order in billing service<care about amount> . Now this is benefit of breaking them into smaller and separated domains.

To define such contracts one can also use ContextMapper.

There are certain outcomes one should take out of this:

• Breaking into smaller pieces is very important so that it becomes easy for people to work on diff. part of the business
• It is very simple when we are clear about the business sub domains .

After this i recommend you guys to go in more depth of DDD and look one more example here.

In next we will look about authentication mechanisms.

Advertisement