Introduction to Domain Driven Design (DDD)

Table of contents

Reading Time: 3 minutes

What is Domain?

To define domain-driven-design we should first establish what we mean by domain. The common dictionary definition of the domain is a sphere of knowledge, influence, or activity. In the context of software engineering, it refers to the subject area on which the application is intended to apply.

For example, if you are building an E-commerce software, in this case, sales will be the domain, and Seller, Buyer, Manager, Customer Executive, etc. will be the domain expert. But it might possible that those people are that expertized in software. So the purpose of DDD is to build a model that the domain experts understand.

Another common term used in software development is domain logic. The domain logic of an application refers to the higher-level rules for how business objects interact with one another to create and modify data.

What is Domain-Driven Design?

Domain-Driven Design is an approach to software design that glues the system’s implementation to a constantly evolving model, leaving aside irrelevant details like programming languages, infrastructure technologies, etc. DDD focuses on three core principles:

It focuses on the core domain and domain logic.
Base complex designs on models of the domain.
Constantly collaborate with domain experts, in order to improve the application model.

A few more common terms that are useful when describing and discussing DDD practices are also defined in Eric Evans in his book.

1. Bounded Context

It is a description of a boundary within which a particular model is defined and applicable.

For example, outside of a Bounded Context, an “add” could mean two different things, either add a product to the cart or add a user. By defining a boundary context, you can determine its meaning.

2. Ubiquitous Language

It is a language, shared by the development team and the domain experts It is used by all team members to connect all the activities of the team with the software.

3. Building Blocks

Domain-driven design also defines a number of high-level concepts that can be used to create, express, and retrieve domain model within a Bounded Context:

4. Aggregate

Aggregates are collections of related Entities and Value Objects. Each Aggregate has an Entity that controls all access to the objects inside the boundary, this entity is the Aggregate Root. Rather than allowing every single entity or value object to perform all actions on its own, the collective aggregate of items is assigned a singular aggregate root item. As a result, external objects no longer have direct access to every individual entity or value object within the aggregate.

5. Services

The Domain Model requires certain actions or operations that are not directly related to an Entity or a Value Object, in that case, such business logic can be implemented as a Service. Services are classes that offer stateless operations.

6. Entity

An object that has a unique identity and consistent thread of continuity. The Identity is maintained via a unique key or a combination of keys.

7. Value Object

An immutable object that describes characteristics, and that does not possess any unique identity is called Value Objects.

8. Repositories

The repository is an interface that handles Read, Updates, and Delete operations. It hides the implementation details from the client. It operates as an abstraction layer over memory, file system, database, etc.

9. Factories

DDD suggests the use of a factory. Using Factories we can create complex objects and aggregates. So that the client has no knowledge of the working of object manipulation. Factories handle the Create operation.