Layered Architecture

Layered architecture is the default. When someone says "standard enterprise application," they are describing layers: presentation, business logic, data access, persistence. Each layer communicates only with the layer directly below it. The pattern is old because it works. It organizes complexity into manageable slices that can be developed, tested, and maintained independently. Most applications start here — and for many applications, this is where they should stay.

1. Strengths Simplicity. Separation of concerns. Each layer has a clear responsibility. Developers can work on the business logic without touching the data layer. The presentation can be redesigned without rewriting the API. Teams can specialize by layer. Testing is straightforward — mock the layer below and test the layer above.
2. Weaknesses Every request traverses all layers, even when the lower layers add no value for that request. The layers create a deployment monolith — changing one layer requires redeploying the entire stack. Scaling is all-or-nothing. If the business logic layer is the bottleneck, you cannot scale it independently without restructuring.
3. When to Use Small-to-medium applications with predictable request patterns. Internal tools, CRUD applications, admin dashboards. When the team is small and the deployment target is a single server or serverless function. When simplicity matters more than scalability.
4. When to Avoid High-scale applications where different components have different scaling needs. Real-time processing systems where the overhead of layer traversal adds unacceptable latency. When the application has distinct bounded contexts that would benefit from independent deployment.