Architecture Patterns on Advanced Beginner

Layered Architecture

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Target Audience: Developers learning architecture patterns for the first time Prerequisites: Basic understanding of Spring Boot MVC patterns Estimated Time: About 15 minutes

The most basic and widely used architecture pattern. If you are learning architecture for the first time, start here. Layered architecture divides software horizontally so each layer has a clear role. It follows the simple but powerful rule that each layer can only call the layer below it.

Hexagonal Architecture

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Target Audience: Developers considering testability and external dependency replacement Prerequisites: Understanding the limitations of Layered Architecture Estimated Time: About 20 minutes

Also known as the Ports and Adapters pattern. An architecture that completely isolates the application core from the external world. The core idea of hexagonal architecture is to place business logic at the center and handle all external interactions through Ports and Adapters. This way, even if external technologies change, core business logic remains unaffected.

Clean Architecture

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Target Audience: Developers of large-scale projects requiring strict dependency management Prerequisites: Understanding of Hexagonal Architecture’s Port/Adapter concept Estimated Time: About 25 minutes

Clean Architecture#

An architecture proposed by Uncle Bob (Robert C. Martin) in 2012. Strictly adhering to the Dependency Rule is the core principle.

Clean Architecture emerged from a persistent problem in software development. When business logic is tightly coupled to frameworks or databases, changing the technology stack or writing tests becomes very difficult. For example, if JPA annotations are directly attached to domain objects, testing the domain logic always requires a database connection. Clean Architecture aims to completely isolate business rules from technical details.

Onion Architecture

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Target Audience: Developers looking for an architecture that works well with DDD Prerequisites: Hexagonal Architecture and Dependency Inversion Principle Estimated Time: About 20 minutes

Onion Architecture#

An architecture proposed by Jeffrey Palermo in 2008. It places the domain model at the very center and wraps it in concentric layers, like an onion.

Onion architecture starts from the limitations of traditional layered architecture. In layered architecture, upper layers depend on lower layers, so changes in the database layer cascade into the service layer. In contrast, onion architecture is designed so that the domain model depends on nothing, and infrastructure depends on the domain. This allows domain logic to express pure business rules regardless of changes in databases, frameworks, or external services. This is precisely why it pairs so well with DDD (Domain-Driven Design).

CQRS

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Target Audience: Developers designing systems with complex query requirements or performance optimization needs Prerequisites: Event-Driven Architecture or basic understanding of event-driven architecture concepts Estimated Time: About 35 minutes Key Question: “When should you separate read and write models?”

Summary
CQRS core: Separate Command (state changes, uses domain model) and Query (reads, uses optimized read model) to optimize each according to its requirements

Analogy: A Library
You can compare CQRS to library operations:

Event-Driven Architecture

d8lzz1gpw@mozmail.com (kimbenji) — Thu, 15 Jan 2026 00:00:00 +0000

Target Audience: Developers who understand domain modeling and transaction concepts Prerequisites: Understanding of Onion Architecture or Aggregate boundary concepts Estimated Time: About 30 minutes Key Question: “When and why should you use domain events?”

Event-Driven Architecture#

Analogy: Company Announcement System
You can think of domain events as a company announcement system:

Event publishing: HR sends out a “New employee has joined” announcement. HR does not know who will see this announcement, nor does it need to.

Event subscription: The IT team sees the announcement and creates an account, the General Affairs team orders business cards, and the Training team schedules onboarding. Each department acts independently.

Loose coupling: The system works even if HR does not know the IT team exists. Even if a “Welcome Gift team” is added later, HR does not need any changes.

Key point: The publisher only announces “something happened,” and subscribers each do what they need to do.