Choosing the Right Architecture Style: Why 'It Depends' Is the Only Honest Answer

1. No Standard Answer

When asked which architecture style to choose, most architects answer "It depends" . This is not evasion but reality: architecture style selection involves trade-offs among architecture characteristics, domain properties, strategic goals, and external constraints. It requires analysis, thought, and weighing — not a lookup in a handbook.

2. Architecture Has Trends

Industry preferences for architecture styles drift over time, driven by several forces:

Observation of the past. New styles emerge from reflecting on painful experiences (e.g., the cost of code reuse).

Ecosystem changes. Tools and practices evolve rapidly; today's standard may be replaced tomorrow.

New capabilities. Paradigm shifts (e.g., containers) change thinking, toolchains, and engineering practices, not just tools.

Acceleration. Change is speeding up; architects are perpetually "on the road."

Domain changes. Business expansion, M&A, new markets force architectural adjustments.

Technology changes. Organizations adopt technologies with clear benefits.

External factors. License cost spikes can force migration regardless of technical merit.

Understanding these trends helps architects decide which trends to follow and when to diverge rather than chasing fads.

3. Pre-Selection Homework

Before choosing a style, architects must clarify:

Domain. Deep understanding of business domain aspects that affect operational architecture characteristics; architects need not be domain experts but must have overall domain awareness.

Architecture characteristics driving structural decisions. Identify and articulate characteristics required to support business and external constraints — a core selection activity.

Data architecture. Collaborate with data engineers on databases, schemas; existing data architecture interactions may force design changes.

Cloud deployment. Designing for cloud differs fundamentally from on-premises: data scale, data movement costs, operational boundaries all change.

Organizational factors. Vendor pricing may rule out ideal designs; frequent M&A may push toward open, integration-friendly architectures.

Processes, teams, and operations. Development processes, architect-ops collaboration, QA processes matter. Lack of mature agile engineering practices makes styles like microservices exceptionally hard to adopt.

Domain-architecture isomorphism. Some domains naturally match certain architecture topologies; others are natural mismatches.

4. Three Key Decisions

After weighing all factors, architects typically make three pivotal decisions:

Monolith or Distributed?

If a single set of architecture characteristics covers the whole design, a monolith suffices — though other factors may still point to distributed. If different system parts need significantly different characteristics, go distributed. The architecture quantum (Chapter 7 concept) is a key tool for this judgment.

Where Does Data Live?

Monoliths usually assume a single relational database (or a few). Distributed systems are more complex: decide which services persist data and how data flows through the architecture to support business processes. Design structure and behavior together; iterate — better combinations emerge through repeated refinement.

Synchronous or Asynchronous Communication?

After data ownership, choose service communication style. Synchronous is simpler but sacrifices scalability and reliability. Asynchronous offers unique performance and scale advantages but introduces data synchronization, deadlocks, race conditions, and debugging difficulty. The recommended default: default to synchronous, use asynchronous only when necessary .

5. Design Outputs

The design process typically produces three artifacts:

Architecture topology (including any necessary hybrids)

Architecture Decision Records (ADRs) for key design points

Architectural fitness functions to guard important principles and operational architecture characteristics

1. Fundamentals of Software Architecture 2nd 第十章 ↩︎