What Is Software Architecture? Core Concepts, Types, and Best Practices

What Is Architecture and Its Essence

In the software industry, the definition of architecture is often debated; this article defines architecture for internet server systems (similar to websites) as the skeleton that supports and links all parts, including components, connectors, constraints, and the principles guiding their design and evolution.

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

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

Constraints : design principles, coding standards, and other rules that limit decisions.

Architecture is a systematic way of thinking, making the most reasonable decisions within resource constraints, and aligning the whole team’s mindset. In short, architecture = components + interactions.

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

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

When to Consider Architecture Design

Complex requirements.

Significant non‑functional requirements.

Long system lifecycle with extensibility needs.

Component‑oriented or integration‑driven systems.

Business process re‑engineering.

Architecture Classification

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

Business Architecture is the strategic layer; Application Architecture is the tactical layer that translates business architecture into concrete solutions; Technical Architecture provides the equipment and tools.

Business architecture defines overall planning, modules, and processes; application architecture determines how these modules are realized; technical architecture selects the underlying platforms and components.

1. Business Architecture (Top‑down View)

Includes business planning, modules, and processes; it breaks down the system into domain models and abstracts real‑world business into objects. The goal is to solve business problems; there is no “optimal” architecture, only the most suitable one.

2. Application Architecture (Logical / Profile Architecture)

Describes how applications are abstracted from hardware, defining logical layers and programming interfaces. It determines which applications exist, their boundaries, responsibilities, and how they cooperate.

Key points:

Responsibility Division : define logical layers, subsystems/modules, and key classes.

Collaboration : interface protocols (exposed APIs) and interaction relationships (call patterns).

Application Layering : horizontal (functional) division such as web front‑end / middle services / background tasks, or vertical (business‑type) division for independent applications.

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

3. Code Architecture (Development Architecture)

Provides concrete guidance for developers. It defines code units (configuration design, frameworks, libraries), organization (coding conventions, module划分, top‑level file structure such as MVC), and dependencies.

4. Technical Architecture (System Architecture)

Specifies the actual runtime components (LVS, Nginx, Tomcat, PHP‑FPM, etc.), their relationships, and deployment strategies. It focuses on non‑functional attributes: high availability, performance, scalability, security, and simplicity.

5. Deployment Topology (Physical Architecture)

Shows the number of nodes, their relationships, high‑availability setups, network interfaces, and protocols. This diagram is primarily of interest to operations engineers.

Application Architecture Evolution

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 files and databases.

Business splitting.

Distributed services.

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

Measuring Architecture Reasonableness

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

Stability

High availability: increase software uptime through testing (unit, integration, fault injection) and coverage.

Efficiency

Documentation throughout the lifecycle.

Scalability: low coupling, abstraction, easy feature addition and technology upgrades.

Reusability: avoid duplicated work and reduce cost.

Security

Data protection via encryption, HTTPS, etc.

Common Architecture Pitfalls

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

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

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

Architecture Knowledge System

Evolution Stages

LAMP on a single server.

Separate application and data servers.

Introduce caching.

Cluster for concurrency.

Read/write DB separation.

Reverse proxy & CDN.

Distributed files & databases.

Business splitting.

Distributed services.

Architecture Patterns

Layered: horizontal layers (application, service, data).

Segmentation: vertical splitting of functions/services.

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

Cluster: improve concurrency and availability.

Cache: optimize performance.

CDN and reverse proxy.

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

Security: encryption, XSS, SQL injection, CSRF, firewalls, SSL.

Core Elements

High performance (frontend, backend, database optimization).

Availability (redundancy, load balancing, backup).

Scalability (cluster expansion, rapid response to traffic spikes).

Extensibility (open‑closed principle, low coupling).

Security (attack mitigation, rate limiting, DDoS protection).