What Exactly Is Software Architecture? A Deep Dive into Systems, Modules, and Design Principles

Definition of Architecture

Architecture is the top‑level structural design of a software system – the arrangement of subsystems, modules and components together with their interaction patterns. A shared definition is required for clear communication.

System, Subsystem, Module, Component

System : a set of related entities that obey defined rules to deliver emergent capabilities (e.g., a car composed of engine, chassis, wheels).

Subsystem : a system that lives inside a larger system.

Module : logical decomposition (service, class, function) aimed at responsibility separation.

Component : physical unit (database, MQ, Nginx) that can be reused across modules.

Framework vs Architecture

A framework provides conventions and baseline functionality (e.g., MVC, Spring MVC, Django). Architecture describes the structural arrangement of the system’s building blocks. Example: Spring MVC is a framework; the Linux kernel architecture describes kernel, user‑space and hardware interaction.

Classification (TOGAF 9 & RUP 4+1)

TOGAF 9 defines four content dimensions: Business, Data, Application, Technology. RUP 4+1 defines lifecycle views: logical, development, process, scenarios, deployment. Combining them yields six practical layers: Business, Application, Data, Technology, Code, Deployment.

Evolution Path

Monolithic → Distributed (service‑oriented) → Microservices.

Monolithic

Typical three‑tier architecture (frontend + business logic + database). Non‑functional needs are met with caching, clustering, read/write splitting, CDN, distributed files/databases. As the codebase grows, maintainability and deployment frequency degrade.

Distributed (service‑oriented)

Each business module is deployed as an independent service on its own server, communicating via defined interfaces. Benefits: lower coupling, clearer responsibilities, easier scaling, reusable services (e.g., a shared price service for web, mobile, PC).

Microservices

Further emphasizes independent deployment, technology‑agnostic stacks, rapid iteration and fault isolation. Trade‑offs: higher operational overhead, network latency, distributed transactions, costly API changes, possible code duplication.

Typical Architectural Problems (illustrated by a real project)

Unclear service boundaries – eight services were created for a simple project that never changed after 2017.

Severe coupling – inter‑service mesh creates a tangled dependency graph.

Service‑level tracing difficulty – after adopting Dubbo, failures caused chaos because no monitoring was in place.

Lack of service monitoring – monitoring added only after incidents.

Technology sprawl – different teams adopted different stacks, leading to architecture drift.

Key Design Principles

N+1 Redundancy : keep at least one extra instance for every critical service (self, client, failure).

Rollback Design : versioned deployments that allow reverting within a bounded time window.

Feature‑Toggle / Degradation Switch : centralized config (e.g., Apollo) to disable risky functionality instantly.

Monitoring by Design : embed observability from the start for self‑diagnosis, self‑heal and resource‑usage visibility.

Multi‑Active Data‑Center : avoid single‑site concentration; consider read/write separation and latency tolerance.

Mature‑First Technology : adopt new tech only after it proves stable in low‑risk components.

Fault Isolation : keep isolation zones independent; do not share hardware or software across zones.

Horizontal Scaling (X/Y/Z axes) : add servers (X), split databases (Y), or partition functionality (Z) without changing existing code.

Buy Non‑Core Services : use cloud‑provided logging, monitoring, etc., instead of building them.

Commodity Hardware : prefer cheap, interchangeable servers for cost‑effective scaling.

Rapid Iteration : small builds, small releases, fast fail‑fast cycles.

Asynchronous Design : decouple slow subsystems to avoid bottlenecks.

Stateless Services : instances hold no persistent state; identical requests yield identical responses, enabling load‑balancing.

Forward‑Looking Design (Now, Now+1, Now+2) : continuously plan the next generation while delivering current value.

Automation : replace manual steps with scripts and pipelines.

Common Pitfalls

Assuming architecture is only the architect’s job – developers must understand it.

Treating the blueprint as finished once drawn – continuous validation is required.

Waiting for a perfect design before coding – iterate from simple to complex (single‑wheel → bicycle → motorcycle → car).

Over‑designing for an uncertain future – early stages need speed, not exhaustive scalability.

Blindly copying large‑company solutions without evaluating fit.

Chasing technology for its own sake rather than business value.

Detailed Classification (TOGAF 9)

Business Architecture : strategy, governance, organization, key business processes.

Data Architecture : logical and physical data assets, data‑management resources.

Application Architecture : blueprint of deployed applications and their interactions.

Technology Architecture : required logical software/hardware capabilities (infrastructure, middleware, network, standards).

Evolution Walk‑through

Monolith : simple three‑tier app (e.g., Java Spring MVC or Python Django). Non‑functional improvements include caching, clustering, read/write splitting, reverse proxy/CDN, distributed files/databases. Problems appear as codebase ballooning, technical debt, low deployment frequency, reliability issues.

Distributed : split business modules into independent services deployed on separate servers. Benefits: lower coupling, clear responsibilities, easier scaling, reusable service layer (e.g., a shared price service). Drawback: remote‑communication overhead.

Microservices : fine‑grained services with independent deployment, technology‑agnostic stacks, rapid iteration. Challenges: higher ops cost, distributed‑system complexity (latency, transactions), API change cost, possible duplicate code. Mitigations are the principles listed above.

Illustrative Principles in Practice

N+1 Design : ensure at least one redundant instance (self, client, failure).

Rollback Design : versioned releases enable quick rollback after catastrophic failures.

Feature Toggle : use a centralized config center (e.g., Apollo) to turn off risky features instantly.

Monitoring Design : embed tracing, health checks and metrics from the beginning so the system can self‑diagnose and self‑heal.

Multi‑Active Data‑Center : ask whether data is centralized, whether read/write is separated, whether schemas are shared, and whether latency is acceptable.

Mature‑First Technology : adopt new tech only after it has proven stable in low‑risk components; then migrate critical paths.

Fault Isolation : enforce “no‑share” and “no‑cross‑zone” principles – each isolation zone has its own load balancer, network, application servers and databases.

Horizontal Scaling (X/Y/Z axes) :

X‑axis: add more servers.

Y‑axis: split databases (sharding, separate read/write).

Z‑axis: split functionality (e.g., per‑user UID partition).

Buy Non‑Core : use cloud logging/monitoring services instead of building them.

Commodity Hardware : cheap interchangeable servers enable cost‑effective scaling.

Rapid Iteration : small builds, small releases, fast fail‑fast cycles accelerate time‑to‑market.

Asynchronous Design : avoid bottlenecks by decoupling slow subsystems.

Stateless Services : no local persistent state; identical responses enable load‑balancing.

Forward‑Looking Design : plan Now, Now+1, Now+2 generations while delivering current value.

Automation : replace manual steps with scripts and CI/CD pipelines.

References

Philippe Kruchten, “The 4+1 View Model of Architecture”, IEEE Software 1995.

TOGAF 9, The Open Group, 2018 edition.

Code example

相关阅读：