Layered Architecture · ThinkerQAQ

This is a historical learning note and may contain outdated or incomplete understanding.

1. What Is Layered Architecture

A common practice of splitting and organizing code units according to roles/responsibilities in the system. Upper layers depend on lower layers. Upper layers can be aware of lower layers, while lower layers cannot be aware of upper layers.

2. Evolution of Layered Architecture

2.1. One Tier

2.2. Two Tiers

Also called standalone architecture. Architecture Pattern - Two Tiers

2.3. Three Tiers

Also called centralized architecture, including C/S and B/S architecture. Architecture Pattern - Three Tiers

2.4. DDD Four-Layer Architecture

2.4.1. Traditional Four-Layer Architecture

Architecture Pattern - Traditional Four Layers

The user interface layer depends on the application layer + domain layer + infrastructure layer. The application layer depends on the domain layer + infrastructure layer. The domain layer depends on the infrastructure layer. In this architecture, the infrastructure layer becomes the core.

2.4.2. Dependency-Inverted Four-Layer Architecture

Architecture Pattern - Dependency-Inverted Four Layers

The infrastructure layer depends on the user interface layer + application layer + domain layer. The user interface layer depends on the application layer + domain layer. The application layer depends on the domain layer. In this architecture, the domain layer becomes the core.

2.4.3. DDD Four-Layer Architecture

Also called distributed microservice architecture.

User interface layer: the entry point for external requests. It mainly contains facade interfaces, DTOs, and code logic for assembling and converting DTO and DO data. Application layer: aggregates logic from multiple domain layers. It mainly contains logic such as event subscription and publishing. Domain layer: core business logic. Infrastructure layer: provides basic services for the other layers, including utility classes, message queues, caches, databases, etc.

Code structure:

├─application
│  ├─event
│  └─service
├─domain
│  ├─aggreate0
│  │  ├─entity
│  │  ├─event
│  │  ├─repository
│  │  └─service
│  └─aggreate1
│      ├─entity
│      ├─event
│      ├─repository
│      └─service
├─infrastructure
│  ├─config
│  └─util
│      ├─api
│      ├─driver
│      ├─eventbus
│      └─mq
└─interfaces
    ├─assembler
    ├─dto
    └─facade

2.5. Hexagonal Architecture

The top and bottom layers of layered architecture can, from another perspective, be viewed as the application’s entry and exit points.

Put all abstractions in the domain layer, and push all details toward application and infrastructure. Generally, from outside to inside, they are infrastructure, application, and domain.

2.6. Onion Architecture

Like hexagonal architecture, it uses adapter code to free the application core from infrastructure concerns and prevent infrastructure code from leaking into the application core.