DDD(Domain Driven Design)

Tags:

What Is DDD(Domain Driven Design)?

  • Domain Driven Design.
  • It is a set of principles and patterns that helps build sophisticated object systems.
  • It is a way of designing by dividing the system by business domain.
  • It is a method of designing around the Domain, which is a set where real-world events occur.
    • For example, in a clothing shopping mall, there may be a domain where customers place orders and another domain where store owners manage products.
    • Designing these domains so that they interact with each other is Domain Driven Design.
  • In Domain Driven Design, domains are separated from each other. From this perspective, applying MSA(MicroService Architecture) makes it easier to design.
  • In DDD, similar objects may exist in different contexts. For example, from the clothing buyer’s point of view, object information may include (name, price), while from the seller’s point of view it may include (madeDate, size, madeCountry). In other words, an object’s role can change depending on context.

Ubiquitous Language

If domain terms are not reflected in code, developers must spend effort interpreting what the code means. Ubiquitous Language improves readability, saves time when analyzing and understanding code, and records terms in a glossary whenever they are defined so that they can be clearly described and used consistently by others later.

What Is a Domain?

  • It is the area of general requirements, or the problem area that software aims to solve.
    • If you are implementing an online bookstore system, the online bookstore is the domain.
  • A domain can be divided into several subdomains.
    • Subdomains of an online bookstore include products, members, orders, settlement, delivery, and so on.
  • Not every domain has fixed subdomains. They vary depending on the situation.
    • For example, whether the target is a company or a user.
  • Software for a specific domain does not have to implement every function the domain provides.
    • It may use an external company’s delivery system or payment system.

Domain Model

  • It is a conceptual representation of a specific domain.
  • It reflects the real world, but it is not a copy of the real world. It abstracts and materializes real subjects so they can be understood better.
  • Using a domain model helps multiple stakeholders understand the domain in the same way and share domain knowledge.
    • To understand a domain, you need to understand the functions it provides and the structure of its main data.
    • A class diagram that shows both behavior and data is usually suitable.
    • UML is not required. The representation method does not matter as long as it helps understand the domain.
  • Multiple subdomains should not be modeled in one diagram.
    • Each subdomain should have its own model.
    • This is because each component of a model becomes fully meaningful only when limited to a specific domain.
    • A product in a catalog and a product in delivery are different.

Entity and VO

  • Entity
    • A table model with a unique identifier.
    • Object identity is assigned based on a unique identifier(primary key).
  • VO(Value Object)
    • A data representation model that has no identifier and is immutable.
    • Object identity is assigned based on state(attributes).

To explain simply in Java, if equals and hashCode use only the id, it is an Entity. If they use all information about the state, it is a VO.

Domain Aggregate

  • A collection of related domain models. A bundle of associated objects is called an aggregate.

Aggregate Root

  • To keep objects belonging to an aggregate in a consistent state, there must be a subject that manages the entire aggregate.
  • The root entity is the representative entity of the aggregate, and the entities in the aggregate belong directly or indirectly to the root entity.
    • The key role of the aggregate root is to coordinate so that aggregate consistency is not broken.
    • The aggregate root provides the domain functions that the aggregate must provide.
      • The root entity Order of an order aggregate provides methods that implement related functions.
        • Changing the shipping address, changing products, and so on.

Domain Model Pattern

  • A typical application architecture consists of four areas(layers).

Presentation: UI Area

  • Receives user requests and passes them to the application layer.
  • The Spring MVC framework is a technology for the presentation area.
  • In a web application, users of the presentation area may be people using a web browser or external systems calling a REST API.

Application: Application Area

  • Shows processing results back to the user.
  • It does not directly implement business logic, but executes functions by combining domain layers.
  • It is a layer that mainly provides actual services(APIs) based on domains and repositories.

Domain: Domain Area

  • Implements the domain rules that the system provides.
  • It is the layer where domain logic proceeds by using Entity and VO(Value Object).

Infrastructure: Infrastructure Area

  • Implements persistence or handles integration with external systems.
  • In other words, it is the layer responsible for communication with the outside, DB, NoSQL, messaging, and similar technologies.