Understanding Software Architecture: Essence, Classifications, and Evaluation Criteria

In the software industry, the definition of architecture is often debated; for internet server systems, architecture is the system's skeleton that supports and links components, connectors, and constraints, guiding design and evolution.

Components include services, independent modules, databases, Nginx, etc.; Connectors cover distributed calls, inter‑process communication, protocols (HTTP, TCP) and interaction relationships; Constraints are rules such as design principles and coding standards.

Architecture is a systematic, reasoned decision made under resource constraints to achieve the most reasonable solution, aligning the whole team’s thinking. In essence, architecture = components + interactions, similar to building or city planning.

The essence of architecture is to reorganize a system orderly so it fits current business development and can scale quickly.

Systems that require architectural design typically have complex requirements, significant non‑functional demands, long lifecycles with extensibility needs, component‑based integration, or business process re‑engineering.

Architecture Classifications

Architecture can be divided into business architecture, application architecture, technical (system) architecture, code (development) architecture, and deployment topology.

Business architecture defines strategy; application architecture translates strategy into concrete modules; technical architecture selects the equipment and platforms to implement the applications.

Business → Application → Technical forms a hierarchy where each layer influences the next.

Business Architecture

It includes business planning, modules, processes, and domain model design, turning real‑world business into abstract objects. The most suitable architecture solves business problems; no architecture is universally optimal.

Understanding business volume, growth trends, and high‑concurrency requirements helps anticipate needs 1‑2 years ahead.

Application Architecture

Application architecture abstracts hardware to logical layers and interfaces; each application is an independently deployable unit defining system boundaries, influencing function organization, code development, deployment, and operations.

Key points: responsibility division (boundary definition, logical layering, subsystem/module definition, key classes) and collaboration (interface protocols, call relationships).

Applications can be divided horizontally (by processing stages such as web front‑end, middle services, background tasks) or vertically (by business domain, e.g., separate inventory, sales, and accounting systems).

Application architecture balances business complexity with technical complexity, ensuring the system remains cohesive while manageable.

Code (Development) Architecture

Code architecture provides concrete guidance for developers, covering configuration design, frameworks, libraries, coding conventions, module division, top‑level file structure (e.g., MVC), and dependency management.

Technical (System) Architecture

Technical architecture determines the actual runtime components (LVS, Nginx, Tomcat, PHP‑FPM, etc.), their relationships, and deployment strategies, focusing on non‑functional attributes such as high availability, performance, scalability, security, and simplicity.

Deployment Topology

Deployment topology shows physical nodes, their interconnections, high‑availability setups, network interfaces, and protocols, defining how the system runs, its performance, maintainability, and extensibility—primarily of interest to operations engineers.

Evolution of Application Architecture

Typical evolution steps: LAMP on a single server → separation of application and data servers → caching → clustering → read/write DB separation → reverse proxy & CDN → distributed storage & databases → business splitting → distributed services.

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

Measuring Architectural Reasonableness

There is no universally optimal architecture; the most suitable one should be efficient, stable, and secure.

Stability : high availability achieved through testing (unit, integration, fault injection) and coverage improvement.

Efficiency : thorough documentation, low coupling, extensibility, and high reusability to avoid duplicated effort.

Security : protect valuable data via encryption, HTTPS, and other standard safeguards.

Common Architectural Pitfalls

1) Assuming only architects need to care about architecture; developers must also understand implementation constraints.

2) Believing the architect’s job ends after the blueprint; continuous involvement is required for successful delivery.

3) Waiting for a perfect design before starting; iterative evolution from simple to complex is essential.

Architecture Knowledge System

Key evolution stages and patterns include layering (horizontal and vertical), distribution, clustering, caching, CDN, reverse proxy, automation (CI/CD, monitoring, alerting), and security measures (XSS, SQL injection, CSRF, WAF, SSL).

Core elements encompass performance, availability, scalability, extensibility, and security, each supported by specific techniques such as load balancing, backup, gray‑release, monitoring, and distributed messaging.