What Is Software Architecture? A Deep Dive into Layers, Types, and Evolution

What Is Architecture and Its Essence

In the software industry, definitions of architecture vary; this article first clarifies the concept, emphasizing that a shared understanding is essential for effective communication.

Architecture exists at many levels: Linux, MySQL, JVM each have their own architecture, and a business system built on these also has an architecture. To discuss architecture, we must distinguish related concepts such as system vs. subsystem, module vs. component, framework vs. architecture.

System and Subsystem

System: a group of interrelated entities that work together to achieve capabilities beyond any single component.

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

Module and Component

Modules are logical units; components are physical units. Modules break down complexity; components can include services, databases, networks, physical machines, MQ, containers, Nginx, etc.

Framework vs. Architecture

Frameworks provide conventions (e.g., MVC, MVP, MVVM) and ready‑to‑use products (e.g., Ruby on Rails, Spring, Laravel, Django). Architecture is the structural design that guides the system.

We define software architecture as the top‑level structure of a software system, a systematic, rational decision made under resource constraints that specifies subsystems, modules, components, their relationships, constraints, and guiding principles, aligning the whole team’s thinking.

Rational decisions through systematic thinking (e.g., technology selection, solution design).

Clear system skeleton (identifying parts).

Collaboration relationships among parts.

Constraints and guiding principles to ensure orderly, efficient, stable operation.

An architect must understand business, maintain a global view, choose appropriate technologies, solve key problems, and guide implementation.

The essence of architecture is to reorganize a system orderly to meet current business needs while remaining extensible.

Architecture Layers and Classifications

Architectures can be classified into business architecture, application architecture, technical architecture, code architecture, and deployment architecture.

Business architecture defines strategy; application architecture translates strategy into concrete solutions; technical architecture provides the equipment and platforms.

Business Architecture (Strategic)

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

Application Architecture (Tactical)

Defines the logical decomposition of the system into deployable applications, their boundaries, responsibilities, interfaces, and collaboration mechanisms. Two common partitioning methods are horizontal (by function) and vertical (by business domain).

Horizontal: e.g., web front‑end, middle services, background tasks.

Vertical: e.g., separate applications for inventory, sales, etc.

Application architecture balances business complexity and technical complexity, ensuring the system remains cohesive yet manageable.

Data Architecture

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

Code Architecture (Development Architecture)

Provides concrete guidance for developers, including configuration design, framework/library choices, coding conventions, module division, top‑level file structure, and dependency management.

Technical Architecture

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

Deployment Topology Architecture

Describes physical nodes, their interconnections, high‑availability setups, network interfaces, and protocols, forming the foundation for operations.

Architecture Levels

Using a pyramid model, higher levels encompass lower ones:

System level – overall relationships and governance.

Application level – structure of a single application and its interaction with the system.

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

Code level – implementation details that enforce the architecture.

Strategic vs. Tactical Design

Strategic design (business architecture) guides overall system design, while tactical design (application architecture) implements it, followed by tactical implementation (technology selection).

Application Architecture Evolution

Business architecture drives production; application architecture translates it; technical architecture provides the tools. Evolution path: monolithic → distributed services → microservices.

Monolithic Applications

Suitable for simple early‑stage businesses; typical three‑tier structure (frontend, business logic, database). Non‑functional improvements include caching, clustering, read/write separation, reverse proxy/CDN, and distributed storage.

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

Distributed Applications

When business complexity grows, services are split into separate modules deployed on different servers, communicating via APIs. Benefits include reduced coupling, clear responsibilities, easier scaling, flexible deployment, and code reuse. Drawbacks involve increased operational overhead and distributed system complexity.

Microservices

Further decomposition into fine‑grained services that each address a specific business function, enabling independent development, fast startup, localized deployment, and technology heterogeneity. Challenges include higher operational demands, distributed complexity, API change costs, and potential code duplication.

Evaluating Architectural Reasonableness

Good architecture balances efficiency, stability, and security. Evaluation criteria include:

Business‑driven adequacy: solves current problems, offers elegant reusable solutions, and anticipates future needs.

Non‑functional adequacy: high availability, documentation, scalability, reusability, and security (encryption, HTTPS, etc.).

Common Architectural Pitfalls

Ignoring key constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making premature decisions.

Blindly following large‑company solutions.

Prioritizing technology over business needs.

Neglecting system testability and incremental design.

Architecture Knowledge System

Evolution Stages

LAMP on a single server.

Separate application and data servers.

Introduce caching.

Scale with clusters.

Read/write separation.

Reverse proxy and CDN.

Distributed files and databases.

Business decomposition.

Distributed services.

Core Elements

Performance (testing, front‑end, application, DB optimization), availability (redundancy, load balancing, monitoring), scalability (clusters, distributed messaging, service orientation), and security (XSS, SQL injection, CSRF, firewalls, SSL).