Domain-Driven Design (DDD) concept was introduced by first Eric Evans in 2003. The concept of microservices did not exist at that time. So basically DDD was introduced to solve the problem of a large monolithic code base. In the monolithic world, once the codebase starts growing with the growth of the business, it becomes difficult to maintain the code organized and structured as it was originally designed. Monolithic applications designed using MVC architecture have good separation between the business layer and the presentation layer. But in the absence of the strict architectural guidelines, the business layer does not provide specific rules to maintain responsibility boundaries between different modules and classes. That’s why as the code base grows it increases the risk of logic breakdown, responsibility leakage between the different components of the application.

DDD attempts to solve the above challenges by keeping your application close to the REAL-WORLD system or more precisely to the concerned business. In DDD, application logic revolves around the business problems with defined boundary contexts. DDD focus on domain modeling. Let’s discuss the key characteristic of DDD

1. Collaborative: DDD is collaborative. Business entities, stakeholders, and developers work together to solve a specific business problem. It is more like an AGILE methodology where collaboration is the key.
2. Data Modeling: Data Modeling defines that the structure of your code should map to the structure of the domain. Here, the domain is not referred to as a business, this can be referred to as the part of the business. The domain can be accounting, storefront, warehouse, etc. The idea behind keeping the code model mapped to the domain is to keep the high-level structure of the application understandable to business users. So when a business expands and one of the domains of the business needs some enhancements in the application, you can change models and logics associated with that domain and keep the other part of the application intact.
3. Incremental: DDD is incremental so you don’t need the entire architecture of the business to be designed upfront. You just need to solve the current problem and then evolve the code as the domain or business grows. Again DDD aligns with AGILE methodology with this characteristic of an incremental approach. An incremental approach is a process or releasing new features quickly and incrementally.

What are Microservices?

In simple words, microservices is about solving a specific problem. In Monolith design, we have a huge code base that is data-driven and tightly coupled. So whenever we need to change the data model the entire monolith design comes into the stake. Even the incremental approach is too cumbersome with a monolith as the entire application has to be tested with all circumstances and scenarios along with different dependency checks to make sure the update is not causing any failures. Microservice architecture solves this problem of monolithic design and provides the freedom to grow the application in any direction.

#domain-driven-design #microservices