Day 23 - Domain-Driven Design - কোড যখন Business-এর ভাষায় কথা বলে

Day 23 - Domain-Driven Design - Code Speaking Business Language

As applications have grown in size, developers have been working with microservices or modular monoliths. Everything seems to be running smoothly, but a new issue has surfaced. During a business team meeting, they mentioned that when a VIP customer confirms an order, the loyalty points need to be added and inventory stock reserved.

However, the codebase does not have any references to VIP customers or loyalty points. Instead, there is a UserEntity, status_flag = 1, and an OrderRepository. The language used by business teams differs significantly from the code's language. This gap often leads to bugs and misinterpretation of requirements in complex projects. Domain-Driven Design (DDD) provides a solution to this problem.

DDD is an approach to software development where business domain or business logic is given more importance than the database or framework. Typically, developers start coding with databases or frameworks (Data-Driven). However, in DDD, the focus is first on understanding the business tasks (Domain), and then the code is organized accordingly.

The main goal is to eliminate the distance between developers and the domain experts (business team) and structure the code in a way that it aligns with the real-world business process.

The first rule of DDD is to speak the same language. Developers and business stakeholders should use the same terms. If business says "confirm order," there should be an "order.confirm()" method in the codebase. If business refers to "customer," the code should use "Customer" instead of "User." This common vocabulary is called Ubiquitous Language. When code and business speak the same language, implementing requirements becomes much easier.

Bounded Context: In a large system, the same word can have different meanings in different contexts. In the sales context, a customer may be defined by name, contact, and purchase history. In the shipping context, a customer may be defined by delivery address and preferred time. In the support context, a customer may be defined by ticket history and complaint log.

These are different Bounded Contexts. Each context has a slightly different model of the Customer. If this is not understood, it can lead to the creation of a God-object, which is a massive User class containing logic for all contexts.

Microservices often use Bounded Contexts to divide services. In a bounded context, Entity and Value Object are the two types of objects that handle data. An Entity has a unique ID and can change its state over time, such as an Order or a Customer. Its ID remains the same even if its properties change. Value Objects do not have an ID and are identified by their values, such as Address or Money. Value objects are always immutable.

An Aggregate is a cluster of objects (Entities and Value Objects) that must be consistent together. For example, an Order can be an Aggregate, containing OrderItems and ShippingAddress (a Value Object). No other class can modify an OrderItem directly; it must be done through the Order. Domain rules must be implemented within the code, not in services or controllers.

Domain Events are emitted when a state change occurs in an Aggregate. Event-Driven Architecture (EDA) works seamlessly with these events. When an Order is confirmed, an OrderConfirmedEvent is fired. Other modules can independently handle this event, such as sending emails or updating inventory.

The Repository Pattern separates the data access layer from the domain layer. The domain layer remains pure, without any dependencies on frameworks. In the domain layer, there is an interface defining the order repository, and the implementation resides in the infrastructure layer.