Application Patterns

Application patterns define how code inside a single process is organised — where business rules live, how dependencies flow, and how the application's interior is divided into meaningful zones.

These are the decisions that shape daily development: which layer owns validation, how do services call each other, where does the database interface live, and how is the codebase testable without a running database?

Patterns in This Section

Pattern	Best For	Article
Layered Architecture	Clear separation of presentation, logic, and data concerns	01-layered-architecture.md
Onion Architecture	Rich domain logic, dependency inversion, testability	02-onion-architecture.md
Ports & Adapters (Hexagonal)	Decoupling core logic from infrastructure, multiple interfaces	03-ports-and-adapters.md
Modular Monolith	Growing monoliths, team separation, pre-microservice structure	../02-modular-monolith-architecture.md
Microkernel	Extensible systems, plugin architectures, tooling	04-microkernel-architecture.md
CQRS	Different read and write models, scaling reads independently	05-cqrs.md
Event Sourcing	Audit trails, event replay, temporal queries	06-event-sourcing.md

Note on Modular Monolith

Modular Monolith is covered in detail in Article 02: Modular Monolith Architecture — including the story of building it in the POS system. It is listed here for completeness as an application organisation pattern, but there is no duplicate article.

How Application Patterns Relate to System Patterns

System patterns determine deployment boundaries. Application patterns determine code organisation within those boundaries.

You can apply onion architecture inside a microservice, use CQRS inside a monolith, or organise any service with a layered approach. The two categories are orthogonal — choose the right one for each concern independently.