도메인 주도 설계를 쉽게 만들어: 개발자의 관점

In our daily development work, we often hear about DDD. But what exactly is DDD?

There have been many articles online before, but most of them are lengthy and hard to understand. This article aims to give you a clearer picture of what DDD is all about.

What is DDD?

DDD (Domain-Driven Design) is a software development methodology for building complex systems by focusing on the business domain. Its core idea is to tightly integrate the code structure with real business needs.

In one sentence: DDD is about using code to reflect the essence of the business, rather than just implementing functionality.

In traditional development, we follow PRD documents and write if-else logic accordingly (how the database is designed determines how the code is written).
In DDD, we work together with business stakeholders to build domain models. The code mirrors the business (when business changes, code adapts accordingly).

Traditional Development Model: A Simple Registration Example

Honestly, it's easy to forget abstract concepts after a while, right? Let’s look at a code example.

Suppose we're building a user registration feature with the following business rules:

The username must be unique
The password must meet complexity requirements
A log must be recorded after registration

In traditional development, we might quickly write the following code:

@Controller
public class UserController {
    public void register(String username, String password) {
        // Validate password
        // Check username
        // Save to database
        // Record log
        // All logic mixed together
    }
}

Some may say, "There’s no way all the code is in the controller — we should separate concerns using layers like controller, service, and DAO." So the code might look like this:

// Service layer: only controls the flow, business rules are scattered
public class UserService {
    public void register(User user) {
        // Validation Rule 1: implemented in a utility class
        ValidationUtil.checkPassword(user.getPassword());
        // Validation Rule 2: implemented via annotation
        if (userRepository.exists(user)) { ... }
        // Data is passed directly to DAO
        userDao.save(user);
    }
}

To be fair, this version has a much clearer flow. Some people might excitedly say, "Hey, we’ve already layered the code! It looks elegant and clean — this must be DDD, right?"

Is Layering the Same as DDD?

The answer is: NO!

Although the code above is layered and structurally divided, it is not DDD.

In that traditional layered code, the User object is just a data carrier (anemic model), and the business logic is offloaded elsewhere. In DDD, some logic should be encapsulated within the domain object — like password validation.

For this registration example, the DDD approach (rich model) would look like this:

// Domain Entity: encapsulates business logic
public class User {
    public User(String username, String password) {
        // Password rules encapsulated in the constructor
        if (!isValidPassword(password)) {
            throw new InvalidPasswordException();
        }
        this.username = username;
        this.password = encrypt(password);
    }

    // Password complexity validation is the responsibility of the entity
    private boolean isValidPassword(String password) { ... }
}

Here, the password validation is pushed down into the User domain entity. In professional terms, business rules are encapsulated inside the domain object — the object is no longer just a "data bag."

Key Design Concepts in DDD

So, is DDD just about pushing some logic into domain objects?

Not exactly.

Besides layering, the essence of DDD lies in deepening business expression through the following patterns:

Aggregate Root
Domain Service vs Application Service
Domain Events

Aggregate Root

Scenario: A user (User) is associated with shipping addresses (Address)

Traditional approach: manage User and Address separately in the Service layer
DDD approach: treat User as the aggregate root and control the addition/removal of Address through it

public class User {
    private List<Address> addresses;

    // The logic to add an address is controlled by the aggregate root
    public void addAddress(Address address) {
        if (addresses.size() >= 5) {
            throw new AddressLimitExceededException();
        }
        addresses.add(address);
    }
}

Domain Service vs Application Service

Domain Service: Handles business logic that spans multiple entities (e.g., transferring money between two accounts)
Application Service: Coordinates the overall process (e.g., calling domain services + sending messages)

// Domain Service: handles core business logic
public class TransferService {
    public void transfer(Account from, Account to, Money amount) {
        from.debit(amount); // Debit logic is encapsulated in Account entity
        to.credit(amount);
    }
}

// Application Service: orchestrates the process, contains no business logic
public class BankingAppService {
    public void executeTransfer(Long fromId, Long toId, BigDecimal amount) {
        Account from = accountRepository.findById(fromId);
        Account to = accountRepository.findById(toId);
        transferService.transfer(from, to, new Money(amount));
        messageQueue.send(new TransferEvent(...)); // Infrastructure operation
    }
}

Domain Events

Use events to explicitly express business state changes.

Example: After a user successfully registers, trigger a UserRegisteredEvent

public class User {
    public void register() {
        // ...registration logic
        this.events.add(new UserRegisteredEvent(this.id)); // Record domain event
    }
}

Differences Between Traditional Development and DDD

Let’s briefly summarize the differences between traditional development and DDD.

Traditional Development:

Ownership of Business Logic: Scattered across Services, Utils, Controllers
Role of the Model: Data carrier (anemic model)
Impact on Technical Implementation: Schema is driven by database table design

DDD:

Ownership of Business Logic: Encapsulated in domain entities or domain services
Role of the Model: Business model that carries behavior (rich model)
Impact on Technical Implementation: Schema is driven by business needs

A DDD Example: Placing an E-Commerce Order

To help you better understand, here’s a concrete DDD case to “quench your thirst.”

Suppose there’s a requirement:

When placing an order, the system must: validate stock, apply coupons, calculate the actual payment, and generate an order.

Traditional Implementation (Anemic Model)

// Service layer: bloated order placement logic
public class OrderService {
    @Autowired private InventoryDAO inventoryDAO;
    @Autowired private CouponDAO couponDAO;

    public Order createOrder(Long userId, List<ItemDTO> items, Long couponId) {
        // 1. Stock validation (scattered in Service)
        for (ItemDTO item : items) {
            Integer stock = inventoryDAO.getStock(item.getSkuId());
            if (item.getQuantity() > stock) {
                throw new RuntimeException("Insufficient stock");
            }
        }

        // 2. Calculate total amount
        BigDecimal total = items.stream()
                .map(i -> i.getPrice().multiply(i.getQuantity()))
                .reduce(BigDecimal.ZERO, BigDecimal::add);

        // 3. Apply coupon (logic hidden in utility class)
        if (couponId != null) {
            Coupon coupon = couponDAO.getById(couponId);
            total = CouponUtil.applyCoupon(coupon, total); // Discount logic is in util
        }

        // 4. Save order (pure data operation)
        Order order = new Order();
        order.setUserId(userId);
        order.setTotalAmount(total);
        orderDAO.save(order);
        return order;
    }
}

Problems with the traditional approach:

Stock validation and coupon logic are scattered across Service, Util, DAO
The Order object is just a data carrier (anemic); no one owns the business rules
When requirements change, developers have to "dig" through the Service layer

DDD Implementation (Rich Model): Business Logic Encapsulated in Domain

// Aggregate Root: Order (carries core logic)
public class Order {
    private List<OrderItem> items;
    private Coupon coupon;
    private Money totalAmount;

    // Business logic encapsulated in the constructor
    public Order(User user, List<OrderItem> items, Coupon coupon) {
        // 1. Stock validation (domain rule encapsulated)
        items.forEach(item -> item.checkStock());

        // 2. Calculate total amount (logic resides in value objects)
        this.totalAmount = items.stream()
                .map(OrderItem::subtotal)
                .reduce(Money.ZERO, Money::add);

        // 3. Apply coupon (rules encapsulated in entity)
        if (coupon != null) {
            validateCoupon(coupon, user); // Coupon rule encapsulated
            this.totalAmount = coupon.applyDiscount(this.totalAmount);
        }
    }

    // Coupon validation logic (clearly owned by the domain)
    private void validateCoupon(Coupon coupon, User user) {
        if (!coupon.isValid() || !coupon.isApplicable(user)) {
            throw new InvalidCouponException();
        }
    }
}

// Domain Service: orchestrates the order process
public class OrderService {
    public Order createOrder(User user, List<Item> items, Coupon coupon) {
        Order order = new Order(user, convertItems(items), coupon);
        orderRepository.save(order);
        domainEventPublisher.publish(new OrderCreatedEvent(order)); // Domain event
        return order;
    }
}

Benefits of the DDD Approach:

Stock validation: Encapsulated in the OrderItem value object
Coupon logic: Encapsulated within methods of the Order entity
Calculation logic: Ensured precision by the Money value object
Business changes: Only require changes to the domain object

Now suppose there's a new product requirement: Coupons must offer “$20 off for orders over $100,” and apply only to new users.

With traditional development, you’d have to modify:

CouponUtil.applyCoupon() logic
The Service layer to add new-user validation

With DDD, you’d only need to modify:

Order.validateCoupon() method in the domain layer

When Should You Use DDD?

So, should DDD be used in every situation? Not really — that would be overengineering.

✅ When the business is complex (e.g., e-commerce, finance, ERP)
✅ When requirements change frequently (90% of internet businesses)
❌ When it's simple CRUD (admin panels, data reports)

I think this quote makes a lot of sense:

When you find that modifying business rules only requires changes in the domain layer, without touching the Controller or DAO — that’s when DDD is truly implemented.