Domain Driven Design - herougo/SoftwareEngineerKnowledgeRepository GitHub Wiki

Domain-Driven Design

Sources

Wikipedia

  • Domain-driven design (DDD) is a software design focusing on modelling software to match a domain according to input from that domain's experts.
  • In terms of object-oriented programming it means that the structure and language of software code (class names, class methods, class variables should match the business domain. For example, if a software processes loan applications, it might have classes like LoanApplication and Customer, and methods such as AcceptOffer and Withdraw.

Domain Model

The Domain Model is your organized and structured knowledge of the problem. The Domain Model should represent the vocabulary and key concepts of the problem domain and it should identify the relationships among all of the entities within the scope of the domain. The Domain Model itself could be a diagram, code examples or even written documentation of the problem. The important thing is, the Domain Model should be accessible and understandable by everyone who is involved with the project.

Strategic design

The main objective in strategic is to define the Bounded contexts, the Ubiquitous Language and the Context Maps together with the entire project team, which are the domain experts and the technical team.

Strategic design has 3 main components.

  • Ubiquitous Language - terminology in your domain that can be understood by all (e.g. developers, domain experts, etc) and used in your code, whiteboard discussions, etc.
    • "ubiquitous" definition from Google: present, appearing, or found everywhere.
  • Bounded Context - A defined part of the software where particular terms, definitions, adn rules apply consistently. For example, in the domain of e-commerce, you have the following examples of contexts: sales, support, accounting, and order. In this example, each have their own interpretation of how customer should be modelled.
    • Each bounded context has its own ubiquitous language (and possibly a DB system and API).
  • Context Map - how the bounded contexts relate to each other.

Tactical Design

Tactical design tools

  • tools concerned with implementation details
  • generally takes care of components inside a bounded context
  • contrary to strategic design, tactical design is expected to change during product development

Tactical design involves the following building blocks

  • entities
  • value objects
  • services
  • repositories
  • factories
  • modules
Entities

An Entity is a potentially changeable object, which has a unique identifier. Entities have a life of their own within their Domain Model, which enables you to obtain the entire transition history of this Entity.

Value Objects

What differentiates a Value Object from an Entity is that, Value Objects are immutable and do not have a unique identity, are defined only by the values of their attributes. The consequence of this immutability is that in order to update a Value Object, you must create a new instance to replace the old one.

Examples of a value object.

  • temperature
  • person's name
Aggregates

It is one of the most important and complex patterns of Tactical Design, Aggregates are based on two other Tactical Standards, which are Entities and Value Objects. An Aggregate is a Cluster of one or more Entities, and may also contain Value Objects. The Parent Entity of this Cluster receives the name of Aggregate Root.

Alternative definition

  • An aggregate is an encapsulation of entities and value objects (domain objects) which conceptually belong together. It also contains a set of operations which those domain objects can be operated on.
  • For example, consider a car with its engine, lights, wheels, and body. Retrieving must retrieve those properties and saving must save those properties.

An aggregate always has a root entity.

Services

Services are stateless objects that perform some logic that do not fit with an operation on an Entity or Value Object. They perform domain-specific operations, which can involve multiple domain objects.

Repositories

Repositories are mainly used to deal with storage, they abstract concerns about data storage. They are responsible for persisting Aggregates.

Factories

Factories are used to provide an abstraction in the construction of an Object, and can return an Aggregate root, an Entity, or an Value Object. Factories are an alternative for building objects that have complexity in building via the constructor method.

Events

Events indicate significant occurrences that have occurred in the domain and need to be reported to other stakeholders belonging to the domain. It is common for Aggregates to publish events.

Modules

Modules are little mentioned by the developers, however, their use can be very interesting. Modules help us segregate concepts, can be defined as a Java package or a C# namespace, and always follow the Ubiquitous Language.