Software Architecture

Appearance

Chapter 19 — Choosing the Appropriate Architecture Style ​

Why This Chapter Exists ​

Architecture selection is often treated like a one-time decision driven by trends: “microservices vs monolith,” “event-driven vs REST,” and so on. In practice, style choice is a trade-off exercise under shifting constraints—technical, organizational, and economic.

This chapter frames architecture selection as choosing the structural shape that best supports the system’s architectural characteristics, while remaining adaptable to changes in tools, paradigms, and business constraints (including licensing, cost, and operational reality).

Architects Track More Than Tools: They Track Paradigms ​

Architects watch for new tools, but also for new paradigms. Sometimes a “minor” change—if it aligns precisely with system goals—can change the entire viability of an approach.

External pressures also matter:

  • a tool can be technically excellent yet become unusable due to licensing cost
  • business constraints can force migrations regardless of engineering preference
  • “current fashion” is not an input that changes the system’s real trade-offs

This is why architecture selection is not just a technical comparison; it is a constraints comparison.

What Architects Design (Structurally) ​

At a high level, an architect designs two things:

  1. The domain solution
    Whatever domain has been specified (what the system does).

  2. The structural elements required for success
    The architectural characteristics—capabilities not directly part of domain behavior but critical for success (scalability, availability, security, maintainability, etc.).

Other specialists (business analysts, domain experts) can help fill gaps in domain knowledge. The harder differentiator between styles is rarely the domain; it is how well each style supports the required characteristics.

Architectural Styles Differ Primarily by Characteristic Support ​

Most architecture styles can implement the same domain behavior. What distinguishes them is:

  • which architectural characteristics they support naturally
  • which characteristics they make expensive
  • where they impose coupling and governance burden

Style selection is therefore “characteristic-first,” not “domain-first.”

Project Factors That Influence Style Choice ​

Architecture selection is also shaped by project context beyond pure design:

  • Software development process
    Release cadence, iteration model, change control.

  • Operations interaction
    Whether the architect/team owns operational responsibility, or hands it off.

  • QA process
    Testing strategy, environment constraints, time-to-test.

These factors influence what is feasible to build and sustain.

Domain / Architecture Isomorphism ​

Isomorphism means a mapping that preserves relations among elements (“equal form/shape”). In architecture, this often shows up as:

Some domains naturally match the topology of certain architecture styles.

Examples of isomorphism-like alignment:

  • step-by-step deterministic workflows align well with pipeline structures
  • customization-heavy products align well with microkernel + plugins
  • strongly bounded business capabilities align well with modular monolith or microservices

Conversely, highly scalable systems struggle with large monolithic designs when:

  • a highly coupled codebase must serve large concurrent user loads
  • shared bottlenecks dominate throughput

This is not a claim that monoliths cannot scale; it highlights that coupling and shared state make scaling more difficult structurally.

The Big Decisions (Structured as Trade-offs) ​

Style selection often reduces to a few high-impact decisions:

1) Monolith vs Distributed ​

A decision about:

  • deployment unit count
  • operational complexity
  • failure modes
  • team autonomy
  • governance surface

2) Where Data Lives ​

A decision about:

  • shared DB vs segmented schemas vs per-service data stores
  • change control and coupling
  • consistency strategy
  • scalability bottlenecks

3) Async vs Sync Communication ​

A decision about:

  • coupling at runtime
  • responsiveness vs determinism
  • error handling and observability

A pragmatic stance often appears:

  • use synchronous communication by default
  • introduce asynchronous communication when it provides clear benefits (decoupling, responsiveness, scaling)

This reflects the fact that async buys flexibility, but also buys complexity.

Example Lens: Modular Monolith vs Microkernel ​

Two examples illustrate how the same domain can map to different structures depending on constraints.

Modular Monolith Lens ​

  • domain elements appear as modules/components
  • changes are domain-oriented
  • structural boundaries are internal but enforceable

A practical forward-looking tactic:

  • if time/resources allow, separate tables and DB assets aligned to domain modules (even within one DB)
  • this reduces coupling and makes future migration to distributed architectures less costly

Customization, if required, is not inherent to this style—so it often becomes part of domain design (implemented through domain modules, configuration, or feature modeling).

Microkernel Lens ​

Microkernel handles variability structurally through plugins.

A common frontend-adjacent variant:

  • API layer provides general information
  • BFF adapters translate that into device-appropriate formats (web/mobile)
  • plugins isolate customization, experiments, or client-specific behavior

Practical Selection Criteria (High-Level) ​

Architecture selection typically evaluates:

  • Domain needs
  • Architectural characteristics that influence structure
  • Data architecture constraints
  • Organizational factors (teams, ownership boundaries)
  • Process factors (release cadence, QA gates)
  • Operational concerns (observability, recovery, on-call maturity)

The output is not “the best architecture,” but a least-worst set of trade-offs given current constraints.

Frontend Context (React / Next.js Lens) ​

Frontend architecture style selection often shows up through:

  • API shape and volatility (contracts, versioning, aggregation)
  • UI composition strategy (single UI vs microfrontends)
  • consistency semantics (immediate vs eventual, polling vs streaming)
  • operational requirements (edge caching, latency budgets, availability targets)
  • In frontend work, many “architecture” trade-offs are experienced as:
  • how often API changes ripple into the UI
  • how much orchestration lives in a BFF vs inside services
  • whether user journeys require synchronous end-to-end completion

Closing Perspective ​

Choosing an architecture style is not about matching a domain to a fashionable topology. It is about matching a domain—and its constraints—to the structural capabilities required for success.

The durable differentiator between styles is characteristic support:

  • what the style makes easy
  • what it makes expensive
  • what it makes fragile

Architectural selection remains an ongoing activity, because tools, paradigms, and business constraints keep changing—and architecture exists inside that context.