Domain-Driven Design

What is domain-driven design?

Domain-driven design (DDD) is a design based on a business domain advocating that the primary focus of the software or application should be to address business needs. Additionally, technological solutions should revolve around the business domain, creating an ubiquitous languageA common and rigorous language for developers and users based on the domain model that helps stakeholders like the technical and business teams sit together and discuss business problems and their solutions.

Terminologies in DDD

Let’s discuss the terminologies, like entity, service, aggregates, and bounded contexts, that are useful in the context of domain-driven design.

Entity

A Plain Old Java Object (POJO) class that allows the creation of distinct objects, with changes in properties over time, and offers different representations is called an entity class. However, the identity of an object never changes and remains intact throughout its lifetime. For reference, the uniquely identifiable value persists in a data store for its lifetime. Therefore, an entity (POJO class) is often mapped to a table in the database using the @Entity annotation of the Spring Framework, and the entity object refers to the row in that table.

Value object

Value objects are immutable and lightweight objects that don’t have a unique identity and are often used for separating computational business logic from entities. Therefore, they don’t share references to the entity. However, they can have a combination of properties of one or more entities.

Service

A service class is a stateless class that sits between entity and value objects and isn’t related to any of them. It provides standalone operations within the context of the domain. Therefore, the Spring Framework offers the @Service annotation to register the Java class as a service component.

Aggregates

Aggregates are a collection of entities and value objects considered a single unit and come under the boundary of a single transaction. An aggregate contains a root object that serves as a reference point for the outside world and ensures the integrity of the aggregate as a whole.

Factories and repositories

Factories handle the beginning of the lifecycle of aggregates, i.e., the creation of objects, whereas repositories manage the object journey and oversee the persistence.

DDD recommends creating a repository per aggregate, not per entity. Therefore, we can use Spring Framework’s @Repository annotation to convert an interface into DDD’s repository.

Bounded contexts

DDD recommends creating a domain model within the bounded contexts in which it’s applicable, usually based on how teams are organized.

It helps draw a fine line between the business needs of the different teams by setting some boundaries and creating domain models that are applicable to them.

Case study: Library management system

Let’s discuss a library management system and apply DDD principles to it.

• Entities:

  • It can have the Book POJO class with properties like id, name, summary, and a list of authors.
  • Similarly, the Author class is required and must include properties like id, firstName, lastName, and a list of books.

• Aggregates: We can define the Library as the aggregate root, representing the library entity that holds a collection of books and authors.

• Repositories: We can implement repositories like BookRepository and AuthorRespoitory that provide methods to persist, retrieve, and query books/authors.

• Services: We can create a service like LibraryService to handle operations involving books and authors. For example, the LibraryService can have methods to add a new book authored by an existing author or retrieve a list of books written by a specific author.

So, we can comprehend that by applying DDD principles, we achieve a rich and expressive model that accurately represents the Library domain. The separation of concerns, clear entity boundaries, and aggregate consistency help us build a robust library management system that aligns with the complexities of the real-world domain.

Application architecture

DDD advocates that the domain models are rich in behavior and business logic and should be free of the underlying infrastructure. Therefore, the following layers in the architecture help to keep domains separate from the infrastructure:

• User interface: This is an interface for the user to interact with the domain model.
• Application layer: This includes the views and other mechanisms to collaborate with the domain.
• Domain layer: This contains entities, value objects, business logic, and the domain model.
• Infrastructure layer: This layer provides the underlying technology and technical implementations that support communication between other layers.

In this lesson, we explored domain-driven design, its terminologies, and the application architecture to define business-rich domain models.