From MVC Three‑Layer to DDD Four‑Layer: How Layered Architecture Evolves

Background

A major version release made the existing three‑layer MVC system hard to modify and test, prompting a migration to a Domain‑Driven Design (DDD) architecture.

Problems with Conventional MVC

Typical MVC development starts from requirements, designs the database schema, then builds DAO, service, and controller layers bottom‑up. This data‑centric approach creates information asymmetry and leads to:

Entity models that are thin data containers, lacking domain behavior.

Business logic scattered across large service classes.

Direct exposure of entity models, increasing coupling and risk.

Mixing field conversion and exception handling inside service methods.

As projects grow, DAO/PO/VO objects proliferate, service classes become thousands of lines, and the codebase accumulates extensive if/else logic, raising maintenance cost.

Why Adopt DDD

DDD encapsulates behavior and logic within domain packages, applying divide‑and‑conquer, abstraction, and domain knowledge to achieve high cohesion and low coupling (as described by Conway’s law). The author lists the following DDD objectives:

Eliminate information asymmetry.

Reverse the bottom‑up MVC design to a top‑down, business‑driven approach.

Split large business requirements into smaller, manageable sub‑problems.

Additional benefits mentioned include rich (non‑anemic) domain models, modularization, clearer expression of business rules, code that serves as design, easier domain knowledge sharing, improved maintainability and readability, and a foundation for mid‑platform architecture.

Layered Architecture Overview

Two variants of layered architecture are described:

Strict Layers Architecture : a layer may depend only on the layer directly below it.

Relaxed Layers Architecture : any upper layer may depend on any lower layer; many systems adopt this style.

DDD Layered Architecture

DDD defines four layers: Presentation (User Interface), Application, Domain, and Infrastructure. The architecture follows a relaxed layering where the Infrastructure layer can be used by the other three layers.

Applying the Dependency Inversion Principle (DIP): high‑level modules and low‑level modules both depend on abstractions; details depend on abstractions, not the other way around. Consequently, the Domain layer no longer depends on Infrastructure; the Infrastructure layer provides implementations via injection.

Layer Responsibilities (Top‑Down)

User Interaction Layer : receives web, RPC, or MQ requests that may modify internal business data.

Application Layer : orchestrates, forwards, and validates use‑case specific operations; differs from MVC services by focusing on coordination rather than containing business logic.

Domain Layer : contains aggregate roots with core logic (rich model). If an aggregate cannot handle a case alone, a domain service may be added, though the ideal is to avoid domain services.

Infrastructure Layer : supplies technical support (e.g., persistence, messaging) to the other layers.

Application services often call repositories directly, illustrating the relationship between the Application and Domain layers.

Query Handling with CQRS

Domain models define business boundaries for data modifications. For read‑only queries and reporting, the architecture commonly adopts CQRS (Command Query Responsibility Segregation) to separate query logic from command logic.

Concrete Example: E‑Commerce Order

In an MVC approach, the workflow starts by designing tables (order, payment, product, etc.) and then adding business logic. Subsequent feature changes—such as order cancellation or returns—require additional tables and modifications that pile up in the service layer.

In the DDD approach, the business boundary is identified first: the Order aggregate. Attributes like address, payment, and product information become part of the Order aggregate. Once the Order domain model is built, repository design and related logic follow naturally, reducing the need for continual schema changes.

Summary

Switching from a bottom‑up, data‑centric MVC architecture to a top‑down, business‑driven DDD architecture addresses the thin entity models, scattered service logic, and high maintenance cost of legacy systems. By defining clear domain boundaries, employing layered separation with DIP, and using CQRS for queries, the system gains higher cohesion, lower coupling, and better alignment with evolving business requirements.

Code example

(细化的领域概念不做过多展开)