Build An Enterprise Systems By Domain Driven Design

One beautiful day, you are being asked by your manager or your customer to build a new system to serve a very complex domain business, but you don't know where to start. I can suggest a solution. Before we go any further, let's list out all the problems of an enterprise system.

• The very first point I can say out loud is maintenance, the business logic always changes besides the growth of the company, and your system needs to adapt to it. The requirement is to minimize the cost and maximize the scalable ability.
• The mixing between presentation, application, and domain logic can be a nightmare for the developers who are in charge of implementing new features or fixing defects.
• The infrastructure and technology at the moment starting building the system can be tied to the system for a long time and hard to upgrade or switch to newer technology.
• The data source for an enterprise system can be fed from many sources and various kinds of data, the system's requirements are to support multi-data source and be easy to swap between them.
• Testability is one more point that you need to pay attention to prevent known bugs, save the cost of fixing bugs, and improve the output to your client.
• Last but not least are speed and stabilization, they are very important to the user experience as the end user feels when they interact with your system every day. As an enterprise system is quite complex in both infrastructure and business logic then it’s hard the expectation on both performance and stabilization, sometime you must balance between them

1) An Introduction to Domain-Driven Design (DDD)

To solve the problems above, I would like to introduce Domain Driven Design (DDD) - a very popular design pattern at this time, written by a very smart author Eric Evans in the book Domain-Driven Design - Tackling Complexity in the Heart of Software (Addison-Wesley Professional 2003. To summarize the idea, we can overview via three points below

• A way of looking at software from the top down. We are not focusing on the details from the beginning or trying to build some features but don’t have an overview of the big picture. Instead of that, we will find out all the main parts of the system and deep dive one by one.
• Focus on the business or event instead of the technology. Business purposes are always the main things that a system builds for, the idea of DDD is bringing out the business logic with all the relationships between them and solving them with the technology. Then the system does not depend on technology and we can easily pick the technology to solve our problems instead of sticking with a specific one.
• Building domains and making the software serve for that. As we do not need to decide which technology will be used from the beginning, then one of the very first steps is to define all the domains.

You just went through the idea, but the question what are really key things that need to be focused on when applying the DDD, let’s go for the Strategic Design, an approach to implementing DDD.

2) Strategic Design

Below is a big picture of DDD, you can have an overview before we go to each node one by one. 

Let’s say, you are going to build a new house, the very first question is what kind of house that you want to build?  

Once you have imaging in your head, then go ahead to all the parts, from master to detail.

3) Ubiquitous Language

In DDD, we have a definition named Ubiquitous Language, which means all the members involved in the project should understand the topic that the other is talking about, no matter whether you are a technical guy or a business person. For example: when building a house, when someone says the keyword kitchen, everyone will understand this is a place for cooking….

4) Domains and Sub-Domains

After we have an overview of the system, we use ubiquitous language to define all the Domains and Subdomains

• Domains: the master objects of the system that we going to build
• Sub-Domains: we break the domains into smaller objects named sub-domain, the way we break them will depend on the business purpose. Inside the sub-domain, we also have three kinds of sub-domains
  • Core: the key objects that your system build for, the business core
  • Generic: the domains serve general purposes such as observability logging, metrics and tracing in architecture design, various cloud services, etc
  • Supporting: similar to the general domain, but the system is more internal or needs some customized development on the basis of the general domain. Such as an e-commerce system, membership, commodity, order, logistics, and other business systems, of course, there are some internally developed technology-type support systems

5) Bounded Context

A bounded context is a boundary within a domain where a particular domain model applies and determines the parts of the domain model that will be applied, it’s usually used to scope a microservice functionality. In the actual case, it will depend on the business to determine the Bounded Contexts and role of sub-domains inside the context. 

For example: in the context of the Human resource department, the customer can be a CV, the interviewing, the probation review, or everything related to the employee, and the product can be the resource information. But in the context of the Development department, the customer can be a requesting for a new feature or a defect, and the product is the new release version for production.

Another example of the context is money, when we build software to manage a coffee shop, money is just a support domain of Order context, it’s used for billing only, and every 5$ is accepted for a cup of coffee. But let's say, we build a system to manage the money-making process of the government, every single 5$ has its own serial number, and can not be replaced by the other 5$, in this case, money is the core domain of this system.

6) Context Map

Is just simple the relationship between bounded context, the way they interact with each other.

Summary

• We know problems of an Enterprise System can be faced
• We know the definition and idea of DDD
  • Ubiquitous Language
  • Domain and Subdomain
  • Bounded Context
  • Context Map

In the next article, we will deep dive into how to use DDD in a real project.

References

• Domain-driven design - Wikipedia
• Domain-‐Driven Design Reference
• An Introduction to Domain Driven Design
• Best Practice - An Introduction To Domain-Driven Design