Understanding Software Architecture: Concepts, Layers, and Evolution

What is Architecture and Its Essence

In the software industry, the definition of architecture varies; we first clarify the concept of architecture as the top‑level structure of a software system, a rational decision made after systematic thinking, balancing trade‑offs under resource constraints, guiding the whole team.

1.1 System and Subsystem

System: a group of related entities that work together to achieve capabilities none of the individual parts can accomplish alone.

Subsystem: a system that exists as a part of a larger system.

1.2 Module and Component

Modules are logical units; components are physical units. Modules decompose a system logically, while components may include services, databases, networks, containers, etc.

1.3 Framework and Architecture

Frameworks are implementation specifications (e.g., MVC, Spring), whereas architecture is the structural design.

Architecture is the top‑level structure, a set of reasonable decisions that define subsystems, modules, components, their relationships, constraints, and guiding principles.

Rational decisions (technology selection, solutions)

Clear system skeleton (components composition)

Collaboration relationships

Constraints and guiding principles

Architects must understand business, control globally, choose appropriate technologies, solve key problems, and guide implementation.

Architecture’s essence is to orderly restructure a system to meet current business growth and enable rapid expansion.

Architecture Layers and Classification

Architecture can be divided into Business Architecture, Application Architecture, Technical Architecture, Code Architecture, and Deployment Architecture.

Business architecture is strategic, application architecture is tactical, and technical architecture provides the equipment.

2.1 Business Architecture (Overview)

Includes business planning, modules, processes, and domain modeling, turning real business into abstract objects.

2.2 Application Architecture (Logical)

Defines independent deployable units, their responsibilities, boundaries, and collaboration (interfaces, call relationships). It can be horizontally (frontend / middle service / background task) or vertically (different business domains) divided.

2.3 Data Architecture

Guides database design, both logical entity modeling and physical storage considerations.

2.4 Code Architecture (Development Architecture)

Provides concrete guidance for developers: code units (configuration, frameworks, libraries), organization (coding standards, module division, top‑level file structure, dependencies).

2.5 Technical Architecture

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

2.6 Deployment Topology (Physical Architecture)

Shows node count, relationships, high‑availability, network interfaces, and protocols; primarily of interest to operations engineers.

Architecture Levels

Using a pyramid model: System level → Application level → Module level → Code level.

Strategic vs. Tactical Design

Strategic design is guided by business architecture; tactical design derives from it and leads to technology selection.

Application Architecture Evolution

From monolithic applications to distributed services and finally micro‑services.

4.1 Monolithic Application

Suitable for simple business; typical three‑tier structure (frontend, middle business logic, database). However, as code grows, complexity, maintenance cost, and deployment frequency suffer.

4.2 Distributed Architecture

Splits business functions into separate services, reducing coupling, clarifying responsibilities, and improving scalability, though it adds remote communication overhead.

4.3 Micro‑services

Each service focuses on a single business capability, enabling fast development, independent deployment, technology‑stack flexibility, but requiring higher operational effort and handling distributed complexities.

Measuring Architecture Rationality

Architecture should be evaluated from business and non‑business perspectives: ability to solve current problems, efficiency, forward‑looking design, stability, high availability, documentation, extensibility, reusability, and security.

Common Architecture Pitfalls

Ignoring key constraints and non‑functional requirements

Over‑designing for an uncertain future

Making premature critical decisions

Blindly following large‑company solutions

Designing for technology rather than business

Architecture Knowledge System

Includes evolution stages (LAMP → tiered → caching → clustering → read/write separation → CDN → distributed storage → business splitting → distributed services) and patterns such as layering, splitting, distribution, clustering, caching, async, redundancy, automation, and security.

Core elements: performance, availability, scalability, extensibility, and security, each with concrete techniques (load balancing, monitoring, backups, etc.).

Finally, the article provides a BAT interview question collection and promotional links for a top‑level architect community.