What Really Defines Software Architecture? Concepts, Layers, and Evolution Explained

1. What Is Architecture and Its Essence

In the software industry, definitions of architecture vary, so we first clarify the concept to ensure effective communication.

Linux, MySQL, and JVM each have architectures; a business system built with Java on MySQL running on Linux also has an architecture. To understand which to focus on, we need to distinguish related concepts: system vs. subsystem, module vs. component, framework vs. architecture.

1.1 System and Subsystem

System : a group of related entities operating under rules to achieve capabilities that individual elements cannot.

Subsystem : a system that is part of a larger system.

1.2 Module and Component

Both are parts of a system, viewed from different angles. A module is a logical unit; a component is a physical unit.

Modules break down complexity (e.g., system, subsystems, services, functions, classes). Components can include services, databases, networks, servers, as well as technical components like MQ, containers, Nginx.

1.3 Framework and Architecture

Frameworks are specifications for implementing components (e.g., MVC, MVP, MVVM) and provide base functionality (e.g., Ruby on Rails, Spring, Laravel, Django). Frameworks are standards; architecture is the structure.

Redefinition of architecture : Software architecture is the top‑level structure of a software system, a systematic, trade‑off‑driven decision under resource constraints that defines the system skeleton—subsystems, modules, components, their collaboration, constraints, and guiding principles—to align the whole team.

Architects need to understand business, make global decisions, choose appropriate technology, solve key problems, and guide implementation.

2. Architectural Layers and Classifications

Architecture can be divided into business architecture, application architecture, technical architecture, code architecture, and deployment architecture.

Business architecture is strategy; application architecture is tactics; technical architecture provides the equipment. Application architecture bridges business and technical layers.

2.1 Business Architecture (Strategic)

Involves business planning, modules, processes, and domain modeling to translate real business into abstract objects.

There is no "optimal" architecture, only the most suitable one that solves business problems.

2.2 Application Architecture (Logical)

Abstracts hardware to applications, defining which applications exist and how they cooperate. It clarifies responsibilities, boundaries, sub‑systems, modules, key classes, interfaces, and collaboration relationships.

Application layering can be horizontal (frontend‑service‑backend) or vertical (by business domain).

2.3 Data Architecture

Guides database design, covering both logical models and physical storage considerations.

2.4 Code Architecture (Development)

Provides concrete guidance for developers; inconsistent code architecture across teams leads to loss of control.

Defines code units (configuration, frameworks, libraries) and their organization (coding standards, module division, top‑level file structure, dependencies).

2.5 Technical Architecture

Specifies runtime components (LVS, Nginx, Tomcat, PHP‑FPM) and their relationships, as well as deployment strategies, focusing on non‑functional requirements such as high availability, performance, scalability, security, and simplicity.

2.6 Deployment Topology (Physical Architecture)

Shows node deployment, high‑availability, network interfaces, and protocols, determining performance, maintainability, and scalability. Primarily concerns operations engineers.

3. Architecture Levels

Using a pyramid model, higher levels contain lower ones:

System level : relationships and governance across the whole system.

Application level : overall architecture of a single application and its interaction with others.

Module level : internal module architecture, data and state management.

Code level : code‑level guarantees for architecture implementation.

Strategic vs. Tactical Design

Strategic design (business architecture) guides overall system design; tactical design (application architecture) follows business architecture; tactical implementation selects technology based on the application design.

4. Evolution of Application Architecture

Business architecture drives application architecture, which in turn relies on technical architecture.

Evolution path: Monolith → Distributed Services → Microservices.

4.1 Monolith

Suitable for simple early‑stage business; typical three‑tier (frontend, business logic, database) architecture, e.g., Java Spring MVC or Python Django.

Non‑functional improvements include caching, clustering, read/write splitting, reverse proxy/CDN, and distributed storage.

Drawbacks: high complexity, technical debt, low deployment frequency, reliability issues, limited scalability, and hindered innovation.

4.2 Distributed

When business grows, split functionality into services deployed on separate servers, communicating via interfaces.

Benefits: reduced coupling, clear responsibilities, easier expansion, flexible deployment, higher code reuse.

Challenges: remote communication overhead.

4.3 Microservices

Complex business scenarios (pricing, inventory, orders) require fine‑grained services. Characteristics include easier development/maintenance, fast startup, localized deployment, and technology‑stack flexibility.

Challenges: higher operational overhead, distributed system complexity, API change costs, and potential code duplication.

5. Measuring Architecture Reasonableness

Architecture serves business; the goal is efficiency, stability, and security.

5.1 Business‑Driven Metrics

Solves current business problems.

Efficiently fulfills requirements with reusable solutions.

Forward‑looking design that remains viable for future growth.

5.2 Non‑Business Metrics

Stability : high availability through testing, fault injection, coverage.

Efficiency : documentation, extensibility, high reuse.

Security : encryption, HTTPS, protection against data leaks.

6. Common Architecture Pitfalls

Missing key constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making critical decisions too early.

Being a mere messenger for client demands.

Lacking foresight while executing.

Ignoring system testability.

Attempting to achieve a perfect design in one step.

7. Architecture Knowledge System

7.1 Architecture Evolution

LAMP on a single server.

Separate application and data servers.

Introduce caching, clustering, read/write splitting, reverse proxy/CDN, distributed storage.

Business splitting and distributed services.

7.2 Architecture Patterns

Layered: application, service, data layers.

Segmentation: vertical functional split.

Distributed: applications, static resources, data/storage, computing.

Cluster: improve concurrency and availability.

Cache: performance optimization (CDN, reverse proxy, local, distributed).

Asynchronous: reduce coupling, speed response.

Redundancy: hot/cold backup for availability.

Automation: CI/CD, monitoring, alerting, failover.

Security: protect against XSS, SQL injection, CSRF, web firewall, SSL, etc.

7.3 Core Elements

Performance : testing, front‑end, application, database optimization.

Availability : load balancing, data backup, automated/gray releases, monitoring.

Scalability : clustering, load‑balanced caching.

Extensibility : distributed messaging, service‑orientation.

Security : XSS, SQL injection, CSRF, firewall, SSL.

8. Recommended Architecture Books

"Large‑Scale Website Architecture: Core Principles and Case Studies"

"Core Technologies of Billion‑Level Traffic Websites"

"Architecture Is the Future"

"Distributed Service Architecture: Principles, Design, and Practice"

"Talking About Architecture"

"12 Practices for Software Architects"