Chapter 10 Flashcards — Layered Architecture Style
flashcards fsa layered-architecture
What are the four canonical layers in a layered architecture, from top to bottom?
?
- Presentation Layer — UI, REST controllers, views, request/response transformation
- Business Layer — domain logic, rules, validation, orchestration
- Persistence Layer — data access, ORM, SQL queries, repository pattern
- Database — actual storage (typically a relational DB)
Requests flow downward from presentation to database; responses return upward.
What is the Sinkhole Antipattern in layered architecture?
?
The Sinkhole Antipattern occurs when requests pass through multiple layers without any meaningful processing in each layer — every layer simply delegates to the next without adding value. It adds indirection and latency with no architectural benefit. A useful heuristic: if more than 80% of requests are pure pass-throughs, the sinkhole antipattern is present and the architecture is adding overhead without value.
What is the Layers of Isolation principle?
?
The Layers of Isolation principle states that each layer is closed — requests must pass through every layer in order and cannot skip layers. The benefit: internal implementation of any layer can be changed without affecting the layers above it. For example, swapping the database technology (Oracle → PostgreSQL) requires changes only in the persistence layer, not in business or presentation layers.
What is a closed layer vs. an open layer in layered architecture?
?
A closed layer must be traversed by all requests — it cannot be bypassed. This enforces isolation. An open layer can be bypassed — layers above it can call layers below it directly. Open layers are used for shared services (logging, caching) that multiple layers need. Open layers must be explicitly documented; undocumented open layers become de facto permission to break all boundaries.
What is architecture erosion in the context of layered architecture?
?
Architecture erosion occurs when developers take shortcuts that bypass layer boundaries — a presentation controller directly calling a persistence repository, or business logic leaking into SQL queries. Each shortcut seems harmless locally, but collectively they collapse the layer isolation that gives the architecture its value. Without governance (fitness functions, code reviews), layered architectures erode toward Big Ball of Mud.
What is the architectural characteristics rating for Overall Agility in layered architecture?
?
Overall Agility: ★☆☆☆☆ (1 out of 5 — Low). Any business change requires coordinating changes across all technical layers (presentation, business, persistence) and all corresponding teams. The horizontal technical partitioning creates structural friction for every cross-cutting feature change.
What is the architectural characteristics rating for Ease of Development in layered architecture?
?
Ease of Development: ★★★★★ (5 out of 5 — Very High). The layered style is extremely well-understood by developers, matches standard training and mental models, has excellent framework support (Spring MVC, Django, Rails, ASP.NET), and requires no distributed systems knowledge. This is its primary strength.
What is the architectural characteristics rating for Scalability in layered architecture?
?
Scalability: ★★☆☆☆ (2 out of 5 — Low). The system can only scale as a single unit. Individual components cannot be scaled independently. The shared database is a hard ceiling on horizontal scalability. Suitable only for low-to-moderate traffic loads.
What is the architectural characteristics rating for Overall Cost in layered architecture?
?
Overall Cost: ★★★★★ (5 out of 5 — Very Low Cost). Single deployment unit, one shared database, minimal DevOps sophistication required, and no distributed systems infrastructure. The total cost of ownership is the lowest of any architecture style.
What is the architectural characteristics rating for Performance in layered architecture?
?
Performance: ★★☆☆☆ (2 out of 5 — Low to Moderate). Every request traverses all layers. The sinkhole antipattern adds latency with no benefit. The shared single database becomes a bottleneck under load. Suitable for low-to-moderate traffic but not high-throughput systems.
What are the star ratings for Testability and Ease of Deployment in layered architecture?
?
Testability: ★★☆☆☆ (2 out of 5) — individual layers can be tested in isolation, but integration tests require the full stack and test suites grow large over time.
Ease of Deployment: ★★☆☆☆ (2 out of 5) — deploying requires releasing the entire monolithic unit; any change requires a full redeployment; deployment risk is high because one bug in any layer affects the entire system.
When should you choose layered architecture?
?
Choose layered architecture when: the team is small (2–8 engineers), the project is budget or time-constrained, the domain is CRUD-heavy and straightforward, you are doing maintenance or legacy modernization, building an MVP or proof of concept, or traffic and availability requirements are low-to-moderate. Its simplicity and cost advantages outweigh its agility limitations in these contexts.
When should you NOT use layered architecture?
?
Avoid layered architecture when: high scalability is needed (different components have very different traffic), high agility is needed (frequent cross-domain changes), teams are organized by domain (Conway’s Law will fight the technical partitioning), you’re targeting microservices (start domain-partitioned instead), or you need fault isolation (any bug brings down the entire system).
What is the data topology of a canonical layered architecture?
?
A canonical layered architecture uses a single shared relational database accessed exclusively through the persistence layer. All application modules share one database schema. This is the tightest coupling point: schema changes require coordinated full-system deployment, and scaling requires vertical scaling of the single database instance.
How does the layered architecture relate to technical partitioning?
?
Layered architecture is the canonical example of technical partitioning — organizing components by technical role (UI/presentation, business logic, persistence/data). All code for a given technical concern is grouped together, regardless of which business domain it belongs to. This means a new feature (e.g., “add order tracking”) requires changes in every layer across all teams.
How does containerization affect a layered architecture deployed to the cloud?
?
Containerizing a layered monolith enables consistent environments and Kubernetes/ECS deployment, but does not solve the shared database bottleneck. The DB remains a single shared instance. True horizontal scalability requires externalizing session state, adding connection pooling (PgBouncer, RDS Proxy), and ultimately re-partitioning the application by domain to eliminate the single-DB constraint.
What governance mechanism best enforces layer isolation in a layered architecture?
?
Automated fitness functions using tools like ArchUnit (Java), Dependency Cruiser (JavaScript), or jQAssistant. These tools run as part of the CI pipeline and assert that presentation-layer classes never import persistence-layer classes directly, enforcing the closed-layer constraint before violations reach production.
What is the team topology that naturally aligns with layered architecture?
?
Layered architecture aligns with skill-based teams: a Frontend/UI Team (owns presentation layer), a Backend Team (owns business and service layers), and a DBA Team (owns persistence layer and database). This is a direct consequence of Conway’s Law — technical team boundaries become architectural layer boundaries.
What is the structural cost of skill-based teams in a layered architecture?
?
Every cross-cutting feature requires coordination across all three teams (frontend, backend, DBA) because each layer must be updated for any new business capability. This is the structural source of the layered architecture’s low agility rating — it is a team coordination problem embedded in the architecture, not merely a code problem.
What is the Lift and Shift cloud deployment strategy for layered architecture?
?
Lift and Shift moves an existing layered monolith from an on-premise server to a cloud VM (e.g., AWS EC2) with minimal code changes. It provides infrastructure cost savings and operational benefits (managed patching, snapshots) but does not achieve cloud-native agility or scalability. The architecture remains fundamentally unchanged.
What is the Service Layer in a 5-tier layered architecture, and when does it help?
?
The Service Layer sits between the Business Layer and the Persistence Layer. It handles transaction management (begin/commit/rollback boundaries), security authorization checks, and reusable coarse-grained operations called by multiple business components or entry points (web, batch, messaging). It helps in large applications with complex transaction semantics. It hurts in small apps where it becomes a thin pass-through — contributing to the Sinkhole Antipattern.
What is architecture erosion and how does it lead to Big Ball of Mud in a layered system?
?
Architecture erosion is the gradual collapse of layer boundaries through developer shortcuts — direct calls from presentation to persistence, business logic leaking into SQL. Each shortcut seems locally justified but collectively destroys the isolation guarantees. Once boundaries are routinely bypassed, the system has the complexity of layers with none of the isolation benefits — it has become a Big Ball of Mud with extra naming conventions.
How does the layered architecture handle session state in cloud deployments?
?
Because cloud deployments may run multiple stateless instances of the application behind a load balancer, any in-memory session state is lost when a request routes to a different instance. Layered applications deployed to cloud must externalize session state to a shared store (Redis, Memcached, or the database) so all instances can access it. This is a necessary adaptation when lifting-and-shifting to cloud environments.
What is the 80% rule for diagnosing the Sinkhole Antipattern?
?
The 80% rule: if more than 80% of requests pass through layers without any meaningful processing being done in each layer (pure delegation), the Sinkhole Antipattern is present. The layers are adding indirection and latency with no architectural value. The remedy is either to collapse the unnecessary layers or to add real behavior to each layer.
What makes layered architecture a good starting point but a poor long-term destination for growing systems?
?
Layered architecture earns maximum ratings for simplicity, development ease, and cost — making it an excellent starting point when speed-to-market and low investment are priorities. But it earns minimum ratings for agility and scalability, which become the dominant concerns as teams and traffic grow. Architects must plan an evolution path (modular monolith → microservices) before the system outgrows the style, not after.
What are the three named antipatterns and risks specific to layered architecture?
?
- Sinkhole Antipattern — layers pass requests through without adding value (>80% pass-through rate)
- Architecture Erosion — layer boundaries bypassed by shortcuts, collapsing isolation guarantees
- Big Ball of Mud Emergence — the end state of unchecked architecture erosion; all architectural structure is lost while code complexity remains
Priority: MEDIUM — important for understanding the canonical baseline style against which all others are compared