What Is Software Architecture? Core Principles, Types, and How to Evaluate Them

1. What Is Architecture and Its Essence

In the software industry, architecture is often debated, but for internet server systems it can be defined as the system's skeleton that supports and links all parts, including components, connectors, constraints, and the principles that guide their design and evolution.

Components: application services, independent modules, databases, Nginx, etc.

Connectors: distributed calls, inter‑process calls, HTTP or TCP protocols, interaction relationships between components.

Constraints: design principles, coding standards, and other rules.

Architecture is a systematic, reasoned decision made under resource constraints to guide consistent thinking across the team. In short, architecture = components + interaction.

It is analogous to building or city planning: a small house can be built ad‑hoc, but a skyscraper requires a comprehensive design.

The essence of architecture is to orderly refactor a system so it aligns with current business development and can scale quickly.

Systems that need architectural design typically have:

Relatively complex requirements.

Significant non‑functional requirements.

Long lifecycle with extensibility needs.

Component‑oriented or integration requirements.

Business process reengineering needs.

2. Architecture Classification

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

Business architecture is strategy, application architecture is tactics, and technical architecture is the equipment. Application architecture bridges the two: it implements business architecture and influences technology selection.

Familiarize with the business, create a business architecture, derive the corresponding application architecture, and finally implement the technical architecture.

Choosing the right application architecture for current needs while ensuring smooth future transitions is a key concern for developers and architects.

2.1 Business Architecture (Top‑down)

Includes business planning, modules, processes, and domain model design, turning real‑world business into abstract objects.

There is no "optimal" architecture, only the most suitable one that solves business problems; ignoring business leads to architectural pitfalls.

Understanding business volume, growth trends, and high‑concurrency requirements helps anticipate needs 1‑2 years ahead, allowing reasonable investment for technology‑driven business growth.

2.2 Application Architecture (Logical/View)

Abstracts hardware to applications, defining layers and programming interfaces. Each part of the business architecture has a corresponding application architecture.

Key points:

Responsibility division: clear boundaries for each logical module or subsystem.

Logical layering (horizontal) vs. vertical splitting by business type.

Collaboration: interface protocols (APIs) and interaction relationships.

Application architecture balances business and technical complexity, keeping the system cohesive while allowing flexibility.

2.3 Code Architecture (Development Architecture)

Provides concrete guidance for developers. Poor code architecture leads to chaotic overall design, especially when different teams use divergent tech stacks.

Defines:

Code units: configuration design, frameworks, libraries.

Organization: coding conventions, module division, top‑level file structure (e.g., MVC), dependencies.

2.4 Technical Architecture (System Architecture)

Determines the actual runtime components (LVS, Nginx, Tomcat, PHP‑FPM, etc.), their relationships, and deployment strategies on hardware.

Focuses on non‑functional attributes: high availability, performance, scalability, security, simplicity, etc.

2.5 Deployment Topology Architecture

Shows physical nodes, their relationships, high‑availability setups, network interfaces, and protocols. It determines how the system runs, its performance, maintainability, and scalability, and is primarily of interest to operations engineers.

3. Application Architecture Evolution

Typical evolution path:

Initial stage: LAMP on a single server.

Separate application and data servers.

Introduce caching for performance.

Adopt clustering for concurrency.

Database read/write separation.

Reverse proxy and CDN acceleration.

Distributed file system and databases.

Business splitting.

Distributed services.

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

4. Measuring Architecture Rationality

Architecture serves the business; there is no universally optimal design, only the most suitable one, judged by efficiency, stability, and security.

Stability

High availability achieved through thorough testing (black‑box, white‑box, unit, automated, fault injection) and increasing test coverage.

Efficiency

Key metrics:

Documentation throughout the lifecycle.

Scalability via low coupling and proper abstraction.

High reuse to avoid duplicated effort and cost.

Security

Protect valuable business data via encryption, HTTPS, and other standard measures.

5. Common Architecture Pitfalls

Assuming only architects handle architecture; developers must also understand it.

Thinking the architect’s job ends after the blueprint; continuous involvement is required.

Chasing a perfect design before any implementation; iterative evolution is more realistic.

6. Architecture Knowledge System

Architecture Evolution

Initial stage: LAMP on a single server.

Application and data server separation.

Caching for performance.

Clustering for concurrency.

Database read/write separation.

Reverse proxy and CDN.

Distributed storage and databases.

Business splitting.

Distributed services.

Architecture Patterns

Layered: horizontal (application, service, data) and vertical splits.

Distributed, clustering, caching, CDN, reverse proxy.

Local and distributed caches.

Asynchronous communication to reduce coupling.

Redundancy (cold/hot standby) for availability.

Automation: release, testing, deployment, monitoring, alerting, failover.

Security measures.

Core Elements of Architecture

High performance (frontend, application, DB optimization).

Availability (redundant servers, load balancing, backup).

Scalability (cluster, rapid addition of nodes).

Extensibility (open‑closed principle, low coupling).

Distributed messaging and service‑orientation.

Security (XSS, SQL injection, CSRF, firewall, SSL).