Domain Driven Design

Introduction

Strategic Design is business concepts and contexts planning, Tactical Design is coding the program and models

Domain Driven Design, or DDD, is an approach to software design that puts the business domain at the centre of the solution. Instead of starting with tables or frameworks, DDD starts with the language and rules that the business already uses, and lets the code follow from there.

A simple wat it is this: Strategic Design is about organising the business, while Tactical Design is about organising the code. Let's look at both with some everyday examples.

Legend

Strategic Design

Ubiquitous Language

Business team and Dev team both using the word Customer

All the team member uses the same terms for the same concepts. That means there's no need to translate between "business language" and "developer language." The words people use in meetings are the same ones you'll find in the code.

Example : The terminology used by the business in the form of Customer should be reflected in the code as class Customer not Client or User or Account.

Bounded Context

Sales Context Product means price and discount, Shipping Context Product means weight and dimensions

The same word can have different meanings in different parts of a system—and that's perfectly fine. What matters is that within each bounded context, everyone shares the same understanding and uses the term consistently.

Example : In the Sales Bounded Context, a Product means the cost and discount, while in the Shipping Bounded Context, a Product refers to the weight and dimension. Even though they are referred to as Product, they are two different domain models because each bounded context has a specific business function.

Context Mapping

Sales Context Order flows through an Anti-corruption layer translation and mapping into Shipping Context Parcel

When two bounded contexts need to communicate, they do so through clearly defined boundaries. Instead of allowing one context's model to spill over into the other, you explicitly define how they interact, keeping each context independent and easier to maintain.

Example : The Shipping context doesn't need to understand concepts like discount codes because those belong to the Sales context. Before information crosses the boundary, an Anti-Corruption Layer (ACL) translates a Sales Order into a Shipping Parcel, ensuring each context can work with its own model without being affected by the other's design.

Tactical Design

Entities and Value Objects

Entity Person keeps its identity even when name or address changes, Value Object Address has no id and is interchangeable when values match

Entity : An Entity is something with a unique identity that stays the same over time, even if its properties change.

Value Object : A Value Object, on the other hand, has no identity of its own. It's defined entirely by its values, so if two value objects contain the same data, they're considered identical and can be used interchangeably.

Example :

A Person is an Entity because they have a unique identity that doesn't change over time. Even if they move to a new home or change their name, they're still the same person.

An Address is a Value Object because it's defined entirely by its values. If two addresses have the exact same street, city, and postal code, they're considered the same address—there's no need for a separate identity or ID.

Aggregates & Aggregate Root

Order aggregate root containing OrderLine entities, external code only enters through the aggregate root, business rules enforced inside

An Aggregate is a group of related objects that are treated as a single unit when making changes. Instead of accessing every object directly, all interactions go through a single Aggregate Root, which enforces the business rules and keeps the entire group in a consistent state.

Domain Events

Order placed raises an OrderPlaced domain event, which the Inventory service and Email service both react to independently

A Domain Event represents something important that has happened in the business. Other parts of the system can respond to it without being directly connected to the part that raised the event, which keeps the system flexible and loosely coupled.

Example : Suppose a customer places an order through a website. As soon as the order is successfully placed, the Order aggregate raises an OrderPlaced domain event.

Two independent services respond to this event:

The Inventory Service reduces the stock for the ordered items.
The Email Service sends an order-confirmation email to the customer.

The Inventory Service and Email Service do not need to communicate with or know about each other. They only listen and react to the same OrderPlaced event.

Repository Pattern

Domain code calls findById on an OrderRepository interface, which can be backed by Postgres, Mongo, or SQL Server

A Repository provides a simple way to retrieve and save domain objects without exposing the underlying database or storage technology. This lets your business logic focus on business rules instead of worrying about how or where the data is stored.

Example : Your code might call orderRepository.findById(123) to retrieve an order. The business logic doesn't need to know whether the data comes from PostgreSQL, MongoDB, or SQL Server. The repository takes care of those details.

Conclusion

Domain Driven Design gives teams a shared language and a set of building blocks—Ubiquitous Language, Bounded Contexts, Entities, Value Objects, Aggregates, Domain Events and Repositories—that keep the code aligned with the business it serves.

Strategic Design helps you draw the right boundaries around the business, while Tactical Design helps you express those boundaries cleanly in code, resulting in software that is easier to understand, evolve and maintain.