How to Choose and Evaluate Architectural Styles from Business Requirements – A Step‑by‑Step Case Study

Architectural Style Classification

Software architecture styles are recurring ways of organizing components, their connections, and constraints. Textbooks often list five major categories: Data‑flow, Call/Return, Data‑centric, Virtual‑machine, and Independent‑Component. The four styles used in the case study are drawn from two of these categories:

Layered        → classic Call/Return style</code>
<code>Event‑driven   → Independent‑Component style</code>
<code>SOA            → service‑oriented, enterprise‑integration style</code>
<code>Microservice   → finer‑grained, independent deployment and business‑boundary style

SOA vs. Microservice

Both focus on services but from different angles. Classic categories describe how components connect (call, data flow, etc.), while SOA and microservices describe how business capabilities are service‑ified, governed, and deployed . Microservices inherit SOA’s core ideas—service contracts, loose coupling, encapsulation—but add finer granularity, independent deployment, data autonomy, and decentralized governance.

Microservices inherit SOA’s contract‑based, loosely‑coupled thinking and can be seen as a refinement rather than a simple rename.

Exam Answer Pattern

A high‑scoring answer must include:

Evidence from the question stem

Business problem or quality attribute

Chosen architectural style

Concrete implementation approach

Expected effect

Cost, risk, or verification method

Five‑Step Selection Method

Identify the mandatory synchronous chain (what the user must see immediately).

Identify optional side‑chains that can be deferred.

Find variation boundaries (team or business boundaries).

Identify external system integration points.

Check the cost of each choice (latency, governance complexity, distributed consistency, etc.).

Combining the Four Styles – Healthcare Platform Example

Layered – organizes the internal code of each service (presentation → application → domain → infrastructure).

Microservices – separate business capabilities such as registration, payment, and reporting, allowing independent scaling.

SOA – provides a unified integration layer for 40 hospitals with heterogeneous protocols (SOAP/XML, REST/JSON, proprietary).

Event‑driven – decouples post‑registration actions (insurance settlement, SMS, audit, analytics) so failures do not block the registration response.

Typical flow (expressed in prose):

Client → API‑gateway → Registration microservice (layered) → publish "registration‑success" event →
   Message broker → SMS service, Audit service, Statistics service
External hospital systems → adapters → SOA integration service → core business microservices

Layered Architecture Details (DDD‑style Four‑Layer Breakdown)

Interface (Presentation) Layer

Responsibility: handle HTTP/RPC/message, convert parameters, return results.

Example: RegistrationController.

Should NOT write business rules or SQL directly.

Application Layer

Responsibility: orchestrate a use‑case, manage transaction boundaries.

Example: sequence – check slot → create registration → persist → publish event.

Should NOT contain complex medical logic.

Domain Layer

Responsibility: encapsulate core business invariants.

Example: validate slot availability, prevent duplicate registration.

Should NOT reference concrete DB, Redis, Kafka APIs.

Infrastructure Layer

Responsibility: implement persistence, caching, messaging, external adapters.

Example: repository implementation, Redis cache, Kafka producer.

Should NOT decide business eligibility.

Event‑Driven Decoupling

Two event patterns are distinguished:

Synchronous event : the producer waits for all listeners before returning (e.g., publishing "order‑created" and waiting for inventory).

Asynchronous event : the producer returns immediately; listeners process later (e.g., writing to a message queue, then returning to the client).

In the registration flow the core transaction finishes synchronously, then an asynchronous event triggers downstream services. Risks include message loss, duplicate consumption, ordering, and eventual consistency; mitigations involve idempotence, sequencing, and monitoring.

ATAM Overview

ATAM (Architecture Tradeoff Analysis Method) evaluates whether key decisions support quality‑attribute scenarios such as performance, availability, security, and modifiability. The process maps high‑priority scenarios to architectural decisions, identifies sensitive points, trade‑offs, risks, and produces concrete improvement or verification tasks.

Quality‑Attribute Scenarios from the Case

Performance scenario : 20 000 concurrent patients during peak hour; 95 % of registration requests must return within 2 seconds.

Modifiability scenario : Adding a new hospital with a new protocol must be completed within 5 person‑days and affect no more than three modules.

ATAM Findings for the Case

Sensitive point : Service‑splitting granularity – too coarse limits independent scaling; too fine inflates remote‑call overhead and consistency costs.

Trade‑off : Synchronous vs. asynchronous insurance confirmation – sync improves immediate consistency but adds latency and propagates failures; async improves response time but requires compensation logic.

Risk : All events depend on a single message broker; its failure would halt insurance, SMS, audit, and analytics, breaking availability and reliability.

Non‑risk : Using adapters to isolate hospital protocol differences; under the 5‑day, ≤3‑module constraint this decision reliably supports modifiability.

Key Takeaways

Architectural styles describe how components are organized; products like Kafka or ESB are implementation mechanisms that can realize a style. The four styles solve distinct concerns—internal code organization, business‑boundary decomposition, asynchronous coordination, and enterprise integration—so they can be combined rather than being mutually exclusive. Every design decision must be paired with its cost or risk to expose trade‑offs, and ATAM provides a disciplined way to challenge those decisions with measurable scenarios.