Domain Driven Design

Domain-driven design (DDD) is a software development methodology that focuses on understanding and modeling the business domain of an application. The goal of DDD is to develop software that closely matches the real-world domain, making it more understandable and maintainable by the stakeholders.

The benefits of using DDD include improved communication and collaboration between the development team and the domain experts, improved maintainability and flexibility of the system, and a better alignment between the business requirements and the software implementation.

Ubiquitous Language

Ubiquitous language is the practice of building up a common, rigorous language between developers and users. This language should be based on the domain model used in the software, hence the need it to be rigorous, since software does not cope well with ambiguity. Language and model should evolve as the team’s understanding of the domain grows.

By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.

Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.

Bounded Context

Bounded context are self-contained parts of the system that have their own domain model and language. Bounded contexts are defined by the business requirements and the organizational structure of the company. They help to manage the complexity of the system by breaking it down into smaller, more manageable parts.

Domain Models

A Domain Model is a representation of the business domain that captures the concepts, relationships, and rules of the domain. The domain model is developed by collaborating closely with domain experts, who provide the knowledge and insights about the business domain.

Terminologies also gets muddled up with other concepts, for instance entity is often used to represent a database table. A service often gets misrepresented with a microservice or a service layer in three tier architecture.

Entities

Objects that have a distinct identity that runs through time and different representations. You also hear these called “reference objects”.

Value Objects

Objects that matter only as the combination of their attributes. Two value objects with the same values for all their attributes are considered equal.

Service Objects

A service is a standalone operation within the context of your domain. A Service Object collects one or more services into an object. Typically you will have only one instance of each service object type within your execution context.

Aggregates

Aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it’s useful to treat the order (together with its line items) as a single aggregate.

An aggregate will have one of its component objects be the aggregate root. Any references from outside the aggregate should only go to the aggregate root. The root can thus ensure the integrity of the aggregate as a whole.

Aggregates are the basic element of transfer of data storage - you request to load or save whole aggregates. Transactions should not cross aggregate boundaries.

Domain Events

A domain event is an immutable data structure that encapsulates the details of the event and the context in which it occurred. Domain events are raised or published by entities or domain services within the domain model when a significant change or occurrence happens, such as when an order is placed, an account is created, or a payment is received. The events are then handled by one or more event handlers, which can perform various actions in response to the event.

Some benefits of using domain events in DDD are:

• Improved modularity and scalability: Domain events provide a way to decouple the different parts of the system and allow them to evolve independently. By using events, the system can be scaled horizontally by adding new event handlers or subscribers, without affecting the rest of the system.
• Better traceability and auditability: Domain events provide a clear record of the changes or occurrences that happened in the system, making it easier to trace and audit the system’s behavior.
• Improved reliability and fault-tolerance: By using a message-based approach, domain events allow for asynchronous communication between the different parts of the system, which can improve the reliability and fault-tolerance of the system.

Repositories

Repositories provide a mechanism for accessing and managing domain models, including querying, saving, and retrieving objects without exposing the underlying persistence mechanism. Persistence is considered a technical detail that should be separated from the domain logic by means of abstraction via repositories.

Anti Corruption Layer

The Anti-Corruption Layer (ACL) is a design pattern in Domain-Driven Design (DDD) that is used to separate the domain model from legacy or external systems that may have a different data model or interface. The goal of ACL is to protect the domain model from the complexities and constraints of the external systems and to ensure that the domain model remains pure and unconstrained.

In ACL, the external system is accessed through an adapter or gateway that is responsible for translating the data and operations of the external system into the domain model’s language. The adapter provides a simple and consistent interface to the domain model, hiding the complexities of the external system.

The benefits of using ACL include improved maintainability, flexibility, and scalability of the system, as well as better separation of concerns between the domain model and the external system. However, the ACL pattern can add complexity to the system and may require additional development effort to implement.

References

• https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/february/best-practice-an-introduction-to-domain-driven-design
• https://martinfowler.com/tags/domain%20driven%20design.html