COLA‑DDD Layered Architecture: A Powerful Tool for Decoupling and Refactoring

Why COLA‑DDD?

In internet development, large‑muddy code, low iteration efficiency, and poor scalability are common. Traditional three‑tier (Controller‑Service‑Dao) struggles with complex business. The COLA‑DDD layered architecture combines Clean Object‑Oriented and Layered Architecture (COLA) with Domain‑Driven Design (DDD) to provide clear layering and strong decoupling.

Design Philosophy

COLA‑DDD puts the domain layer at the center, forming a concentric‑circle model. External adapters connect technical components (Web, DB, MQ) to the domain via ports, achieving a “stable core, flexible periphery”.

Core Layers

Domain Layer – the heart, containing aggregate roots, domain models, CQE (Command/Query/Event), and ports. It has no technical details such as DB or network.

Application Layer – orchestrates business processes, contains application services, event handlers, DTOs, and defines transaction boundaries.

Adapter Layer – translates external formats to domain ports; includes Web controllers, RPC adapters, message adapters, and isolates external changes.

Infrastructure Layer – provides generic technical capabilities (gateways, repositories, component wrappers, utilities, configuration).

Application SDK – exposes domain capabilities as a “socket”, with different strategies for small vs. large organizations.

Key Advantages

Business cohesion : Pure domain focus keeps core rules in one place, reducing maintenance cost and easing onboarding.

CQRS support : Separates write commands from read queries, allowing read models to be optimized and improving throughput.

Event‑driven : Domain events enable asynchronous extensions without touching core code, adhering to the open‑closed principle.

Technical isolation : Changing a tech component (e.g., Redis → Memcached, Spring Boot 2.x → 3.x) only requires modifications in the adapter or infrastructure layer, protecting core business logic.

Practical Roll‑out Guidelines

Domain modeling first : Conduct event‑storming with business and technical staff, identify aggregates and boundaries, and avoid over‑design for simple scenarios.

Strict layer boundaries : Outer layers may depend on inner ones, but inner layers must not depend on outer layers; enforce via Maven modules.

Incremental adoption : Start with an isolated vertical slice (e.g., order management), validate migration, then expand; for new projects embed the architecture from the design phase.

Conclusion

The essence of COLA‑DDD is not exotic technology but a decoupled, domain‑centric structure that enables rapid business iteration, scalable growth, and low‑risk technical evolution, positioning it as a mainstream approach for enterprise‑level systems.