# 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](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns)         | Clear separation of presentation, logic, and data concerns     | [01-layered-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns/01-layered-architecture)         |
| [Onion Architecture](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns)           | Rich domain logic, dependency inversion, testability           | [02-onion-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns/02-onion-architecture)             |
| [Ports & Adapters (Hexagonal)](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns) | Decoupling core logic from infrastructure, multiple interfaces | [03-ports-and-adapters.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns/03-ports-and-adapters)             |
| [Modular Monolith](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns)             | Growing monoliths, team separation, pre-microservice structure | [../02-modular-monolith-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/02-modular-monolith-architecture)         |
| [Microkernel](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns)                  | Extensible systems, plugin architectures, tooling              | [04-microkernel-architecture.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns/04-microkernel-architecture) |
| [CQRS](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns)                         | Different read and write models, scaling reads independently   | [05-cqrs.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns/05-cqrs)                                         |
| [Event Sourcing](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns)               | Audit trails, event replay, temporal queries                   | [06-event-sourcing.md](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/application-patterns/06-event-sourcing)                     |

## Note on Modular Monolith

Modular Monolith is covered in detail in [Article 02: Modular Monolith Architecture](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/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](https://blog.htunnthuthu.com/architecture-and-design/architecture-and-patterns/software-architecture-101/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.