Software Architecture Decoded: Four Puzzle Pieces That Define System Design

This article is the first in the "Software Architecture from Beginner to Giving Up" series; references are listed at the end.

1. Etymology and Origins

The term "architecture" derives from ancient Greek arkhitekton : arkhi- meaning "chief" and tekton meaning "builder", so literally "chief builder".

Romans adopted the word as Latin architectura ; the suffix -ura denotes "action or result", shifting the meaning from a person to "the work, art, or method of the chief builder".

Roman architect Vitruvius's De architectura systematically proposed three core principles of building: firmness, commodity, and delight (坚固、实用、美观).

Why was this physical-world concept borrowed into virtual software engineering? The answer traces back to the software crisis of the 1960s–70s.

At that time, software system complexity kept climbing, making overall coordination and management impossible. Just as ancient construction required a chief builder to oversee the whole, software engineering needed someone to design module boundaries, interface standards, data flows, and dependencies from a global perspective—balancing functionality, performance, and maintainability.

Thus software engineering adopted the architecture concept: software architecture concerns not only code composition but emphasizes the art and method of whole-system design, giving Vitruvius's three principles new meaning.

2. Four Dimensions of Software Architecture

The building metaphor is the most intuitive way to understand software architecture, yet it is not comprehensive. The current mainstream definition of software architecture comprises four dimensions:

Architecture style (architecture style)

Architecture characteristics (architecture characteristics)

Logical components (logical components)

Architecture decisions (architecture decisions)

These four dimensions are like four puzzle pieces: each is independent yet interrelated; only when correctly assembled do they reveal the complete picture.

2.1 Architecture Characteristics

Architecture characteristics are the cornerstone of software architecture. Without them, architecture decisions have no basis and trade-offs cannot be analyzed.

For example, when choosing a database for a new system—relational, key-value, or graph—the answer depends on what you prioritize. If extreme read/write performance is paramount, a key-value store (e.g., Redis) is the natural choice; if data relationship integrity and transaction support are critical, a relational database (e.g., PostgreSQL) fits better; for complex relationship queries and social-network scenarios, a graph database (e.g., Neo4j) excels. The same technical selection yields completely different conclusions under different characteristic priorities.

Informally, architecture characteristics are also called "non-functional requirements", typically words ending in -ility : availability, reliability, testability, scalability, security, agility, fault tolerance, elasticity, recoverability, performance, deployability, learnability, etc.

In short: Architecture characteristics are the key capabilities on which system success depends; they dictate the direction of technology selection and define the evaluation criteria for architecture decisions.

2.2 Logical Components

Architecture characteristics define system capabilities; logical components define system behavior.

Logical components are the building blocks of a system, just as rooms are the basic units of a house. Each logical component carries a specific function. In a typical e-commerce system, logical components might include: User Service, Product Service, Order Service, Review Service, etc. Each component performs its own duty, interacting through well-defined interfaces to jointly support the complete system functionality.

Logical components are interrelated modules , but this interrelation should be manageable and layered, not an ad-hoc weaving.

2.3 Architecture Style

Architecture style defines the overall shape and properties of a software system. Microservices excel at scalability and agility; layered architecture is simple and economical; event-driven architecture responds quickly and scales well.

Choosing the right style is critical—moving from a monolithic layered architecture to microservices is no trivial task. Architecture style has no absolute good or bad, only fit or misfit. Selecting an architecture style is essentially a decision made after weighing team capability, business complexity, and long-term evolution needs.

Architecture style shapes the system and helps achieve its goals.

2.4 Architecture Decisions

Architecture decisions are choices made about system structure that have long-term, significant impact. As constraints, they guide development teams in planning and building the system. Each architecture decision is like a constitutional clause for the project: once established, it becomes the baseline for all subsequent decisions.

The scope of architecture decisions is broad, from macro to micro: Should the system adopt microservices or a monolith? How should services communicate—synchronous REST or asynchronous messaging? How is data shared across services—independent databases per service or a shared database? How are authentication and authorization implemented? What are the logging and monitoring standards? These decisions are critical because they have a cumulative effect: a single decision's impact may be negligible, but many decisions stacked together shape the system's DNA and determine its evolutionary trajectory.

Architecture decisions are the intersection of technical judgment and business judgment. They require engineers to have technical vision and a clear understanding of business priorities. 1. Head First Software Architecture, Chapter 1 2. Fundamentals of Software Architecture, 2nd Edition, Chapter 1