Trusted answers to developer questions
Trusted Answers to Developer Questions

Related Tags

What is Domain Driven Design?

Mashal Abbas

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

Domain Driven Design (DDD) is a software development method that was introduced in Domain-Driven Design: Tackling Complexity in the Heart of Software, a book written by Eric Evans.

The word domain in Domain Driven Design refers to the field of knowledge in which the software is intended to apply.

In DDD the focus of development is shifted from the technicalities of the software to the constantly evolving model. So, it focuses on the domain problem and the domain logic that solves it.

Since DDD focuses on domain logic and an evolving model, changes in iterations increase the complexity of the system. Below are different DDD terms and practices that are put into action to simplify the process.

  • Bounded Context: This is a boundary that is created to define different contexts. It is used to divide teams so that each domain expert works in their own bounded context and there is a clear separation of concern.

  • Context Mapping: This is used to determine how different bounded contexts are related.

  • Shared Kernel: The intersection of two different bounded contexts.

  • Model: An abstract system that is formed with the domain knowledge to solve a domain problem.

  • Ubiquitous Language: A standard language used by the team that is structured around the domain model. DDD requires the development team to not only have the technical expertise but to also gain knowledge about the domain. The communication done between the domain experts and developers is done with ubiquitous language.

The workings of DDD

DDD proposes to have a set of defined constructs that can be used to build models. Having these predefined elements makes it easier for both the developers and domain experts to understand the model.

Entities: Is an object that has a thread of continuity. It has a unique identifier but it is not defined by its attributes. The object is mutable and the attributes can change but the identity will remain the same. For example, think of an order given in a restaurant. The order has a unique order number associated with it, however, the order changes its attribute from ordered, to cooking, to served.

Value Object: Is an object that defines a characteristic. It is immutable cannot be changed. These are attributes of entities that can be shared by multiple entities. The only way to change this attribute is to create a new instance and replace the old one.

Domain Event: Is an object that is used to define an event. Domain events are those which that have significant impact to the domain experts, therefore, not all technical events will be domain events.

Services: Is any stateless operation that does not affect or is related to an entity or a value object.

Aggregate: Is a group of entities and value objects defined in a boundary. The entities and value objects in an aggregate cannot be accessed by an external object except for one entity that is known as the Aggregate Root. The aggregate root is the only entity which other objects can interact with and send instructions to the whole of the aggregate.

Repositories: Is an interface where the entities, value objects, and aggregates can be accessed. Different methods can be defined to create, delete, and modify these objects. The repository makes it easier for the user to access these objects without getting into the complexities of where and how they are stored.

Factories: Another abstraction that is used to make complex objects, such as an aggregate. This will enable the user to create these objects with an atomic function without worrying about the underlying working of the system.

Advantages of DDD

The biggest advantage of DDD is that it is heavily dependent on domain rather than the implementation itself. This leads to the final product being suitable and accurate for that domain and its experts, especially in the cases of complex domain logic.

DDD also aids communication between the developers and the domain experts with the use of ubiquitous language and the domain model.

Since DDD emphasizes on an evolving model, it inherently promotes a flexible system. Furthermore, the defined abstractions make it easier to maintain and sustain the system.

Disadvantages of DDD

DDD requires robust domain knowledge, which might be require substantial interference of external domain experts in the development life cycle. This can be difficult to manage.

Furthermore, DDD is an overkill for projects with marginal domain complexity as it might add unnecessary complexities.

RELATED TAGS

Grokking Modern System Design Interview for Engineers & Managers

Ace your System Design Interview and take your career to the next level. Learn to handle the design of applications like Netflix, Quora, Facebook, Uber, and many more in a 45-min interview. Learn the RESHADED framework for architecting web-scale applications by determining requirements, constraints, and assumptions before diving into a step-by-step design process.

Keep Exploring