Understanding Domain-Driven Design (DDD) and Its Role in Solving CRUD Problems

Hello DDD

When first encountering Domain‑Driven Design (DDD), the author was attracted by many new concepts—domain, sub‑domain, aggregate, aggregate root, value object, ubiquitous language—and felt both excitement and confusion about how to apply them in practice.

Problems with Traditional Development

The classic three‑layer MVC architecture separates presentation, controller, and model layers, with the model further split into service and DAO. This leads to overly heavy service classes that accumulate responsibilities such as business logic, permissions, transactions, and external notifications, causing tight coupling, difficult testing, and high maintenance cost.

A concrete example shows a EquipmentServiceImpl that directly sends emails and updates equipment status, illustrating how adding inventory checks or manager notifications would further bloat the service.

@Service
public class EquipmentServiceImpl implements EquipmentService {
    @Autowired private EmailService emailService;
    @Autowired private EquipmentRepository equipmentRepository;

    public void setEquipmentBroken(Long id) {
        Equipment equipment = equipmentRepository.findById(id);
        equipment.setStatus(Equipment.StatusEnum.BROKEN);
        emailService.sendEmail();
    }
}

Such tightly coupled services become a nightmare as business complexity grows, and developers often struggle with unclear requirements and poor communication with product owners.

Various Issues with CRUD

CRUD (Create, Read, Update, Delete) operations dominate most applications because databases are ubiquitous, but they introduce several problems:

Object‑relational impedance: mapping objects to relational tables creates redundant DTOs, null fields, and duplicated queries.

Inheritance mismatch: relational tables cannot naturally represent inheritance hierarchies, leading to fragmented data and extra joins.

Business‑model disconnect: CRUD focuses on data manipulation rather than business intent, making it hard to capture why a change occurs.

Collaboration difficulty: concurrent updates cause conflicts and increase merge complexity.

The "U" problem: a generic update method can hide important domain actions such as deposit, withdrawal, or transfer, and makes audit trails harder.

Lack of intent and history: CRUD does not record the purpose of changes or maintain a full change history without additional effort.

Why Use DDD?

DDD helps solve micro‑service decomposition by defining clear boundaries through aggregates and bounded contexts, aligning technical design with business capabilities. It also provides tools for handling system complexity via abstraction, divide‑and‑conquer, and knowledge encapsulation.

What Is DDD?

Domain‑Driven Design, introduced by Eric Evans in 2003, is an object‑oriented modeling approach that translates business concepts into software types, behaviors, and relationships, thereby reducing complexity and improving extensibility.

DDD History

Although DDD did not gain immediate popularity due to its steep learning curve, it resurfaced with the rise of micro‑services around 2013, as its focus on bounded contexts matched the need for business‑centric service boundaries.

DDD Benefits

Strategic Design (Do Right Things)

Strategic design uses ubiquitous language, bounded contexts, and domain models to align business experts and developers, ensuring that each context has its own autonomous model.

Tactical Design (Do Things Right)

Tactical patterns such as Event Sourcing and CQRS address the shortcomings of CRUD. Event Sourcing records every state‑changing event rather than the final state, while CQRS separates read and write models for efficient querying.

public void setEquipmentBroken(Long id) {
    Equipment equipment = equipmentRepository.findById(id);
    equipment.broken();
    eventBus.publish(new EquipmentBrokenEvent(equipment.id));
}

Evolutionary Process

DDD follows a spiral‑like iterative process: strategic design defines contexts and boundaries, tactical design implements models, and continuous refactoring evolves the domain model while preserving business intent.

Summary

DDD provides a systematic way to abstract complex business logic into well‑defined domain models, replace anemic CRUD‑centric code with rich behavior, and support micro‑service architectures. It is especially valuable for complex domains, while simple projects may still favor straightforward CRUD implementations.