Application Architecture

Core Philosophy

1. Dependencies point inward. Business logic never depends on frameworks, databases, or HTTP. Infrastructure depends on the domain, never the reverse.
2. Boundaries are the architecture. The placement and enforcement of module boundaries matters more than which pattern name you pick.
3. Match complexity to the problem. CRUD apps do not need hexagonal architecture. Complex domains do not survive without explicit modeling. Select the lightest pattern that controls your actual complexity.
4. Make the implicit explicit. Use cases, domain rules, and module contracts should be readable in code, not buried in service classes or controllers.
5. Delay distribution, enforce modularity now. A well-bounded modular monolith can be split into services later. Poorly structured microservices cannot be easily merged back.

Quick-Start: Common Problems

"How should I structure this app?"