How DDD + CQRS Can Turn Chaotic Java Code into Clean, Scalable Architecture

Monolithic service methods that mix validation, business logic, persistence, and response construction create unreadable code and technical debt. The article identifies three root causes: a “one‑pot” service, treating the database as the source of truth, and ambiguous terminology between business and technical entities.

Why DDD Helps

Domain‑Driven Design (DDD) aligns technical implementation with business concepts, acting as a translator between the two domains.

Key DDD Concepts

Domain : the core problem space (e.g., online ordering, covering ordering, payment, delivery).

Aggregate Root : the authoritative entity that controls all modifications within its boundary (e.g., Order).

Value Object : immutable attribute groups without independent identity (e.g., an address composed of province, city, street).

Domain Service : operations that involve multiple aggregates (e.g., calculating order discounts).

Bounded Context : a self‑contained sub‑domain with its own model (e.g., Order Processing vs. Dish Management).

Domain Event : significant business occurrences that trigger downstream actions (e.g., OrderCreatedEvent).

DDD Layering Example

Traditional three‑layer code often collapses all logic into a single controller or service method. The DDD‑oriented version separates concerns:

@RestController
public class OrderController {
    @PostMapping("/orders")
    public Result createOrder(@RequestBody CreateOrderCommand cmd) {
        return orderApplicationService.createOrder(cmd);
    }
}

@Service
public class OrderApplicationService {
    public Result createOrder(CreateOrderCommand cmd) {
        Order order = orderFactory.create(cmd);
        orderRepository.save(order);
        return Result.success(order.getId());
    }
}

public class Order {
    public static Order create(UserId userId, List<OrderItem> items, Coupon coupon) { ... }
    private void calculateTotal() { ... }
    public void applyCoupon(Coupon coupon) { ... }
}

Introducing CQRS

Command‑Query Responsibility Segregation separates write (command) and read (query) concerns, preventing them from interfering. The command side executes full DDD workflows; the query side reads from optimized read models (e.g., Elasticsearch, dedicated read‑only tables).

@Service
public class OrderCommandService {
    public OrderId createOrder(CreateOrderCommand cmd) {
        Order order = Order.create(...);
        orderRepository.save(order);
        return order.getId();
    }
}

@Service
public class OrderQueryService {
    public List<OrderSummary> getUserOrders(Long userId) {
        return orderSummaryRepository.findByUserId(userId);
    }
}

Data synchronization can be achieved via event‑driven listeners, dual‑write, or CDC; the article recommends event‑driven sync for consistency and scalability.

Step‑by‑Step Migration

Identify bounded contexts (e.g., Order, DishStock, Payment, Delivery).

Define aggregate roots for each context.

Model domain events (e.g., OrderCreated, PaymentCompleted, OrderAssigned).

Implement domain logic inside aggregates and domain services.

Introduce CQRS: separate command and query services, create read models, and set up event listeners for synchronization.

Pitfalls & Best Practices

Over‑design : avoid turning simple enums into full value objects.

CQRS misuse : not every CRUD admin screen needs CQRS; apply it where read/write load differs.

Eventual consistency : handle read‑side latency gracefully (e.g., show a loading view if data has not yet synced).

Adoption Roadmap

Phase 1 (small project) : apply DDD layering, keep a single database, split command/query services.

Phase 2 (growing project) : introduce true CQRS with separate read/write stores and event‑driven sync.

Phase 3 (large system) : decompose bounded contexts into microservices, each using DDD+CQRS and communicating via events.

Concrete DDD Implementation (Order Example)

public class Order {
    private OrderId id;
    private List<OrderItem> items;
    private Money totalAmount;
    private OrderStatus status;
    private UserId userId;

    public static Order create(UserId userId, List<OrderItem> items, Coupon coupon) {
        Order order = new Order();
        order.id = OrderId.generate();
        order.userId = userId;
        order.items = items;
        order.status = OrderStatus.CREATED;
        order.calculateTotal();
        if (coupon != null) {
            order.applyCoupon(coupon);
        }
        order.addDomainEvent(new OrderCreatedEvent(order.id, userId, order.totalAmount));
        return order;
    }

    private void calculateTotal() {
        this.totalAmount = items.stream()
            .map(i -> i.getPrice().multiply(i.getQuantity()))
            .reduce(Money.ZERO, Money::add);
    }

    public void applyCoupon(Coupon coupon) {
        if (!coupon.isValid()) {
            throw new BusinessException("Invalid coupon");
        }
        if (this.status != OrderStatus.CREATED) {
            throw new BusinessException("Coupon cannot be applied in current state");
        }
        // discount calculation logic …
    }
}

Event‑Driven Synchronization Example

@Component
public class OrderEventHandler {
    @EventListener
    public void handleOrderCreated(OrderCreatedEvent event) {
        orderSummaryRepository.syncFromEvent(event);
        orderStatisticsRepository.update(event);
        redisTemplate.opsForValue().set("order:" + event.getOrderId(), event.getOrderSummary());
    }
}

Read‑Side Performance Boost

Before CQRS, a query might join multiple tables, taking >200 ms. After CQRS, the query reads a pre‑computed view (e.g., Elasticsearch), reducing latency to <20 ms and lowering database CPU usage.

Response time: 200 ms → 20 ms (10× faster)

CPU usage: 80% → 30% at peak

Developer experience: complex SQL → simple repository call