What Is Software Architecture? Core Concepts, Layers, and Evolution Explained

What is Architecture and Its Essence

In the software industry, definitions of architecture vary; this article first defines the concept to ensure clear communication.

Linux, MySQL, JVM each have architectures; a business system built with Java, MySQL, and Linux also has an architecture. To understand which to focus on, we clarify related concepts: system vs subsystem, module vs component, framework vs architecture.

System and Subsystem

System: a group of related entities that work together to achieve capabilities beyond individual parts.

Subsystem: a system that is part of a larger system.

Module and Component

Both are parts of a system; a module is a logical unit, a component is a physical unit.

Modules decompose a system logically, can be of various granularity (subsystem, service, function, class, etc.). Components include services, databases, networks, machines, MQ, containers, Nginx, and other technical pieces.

Framework vs Architecture

Frameworks are specifications (e.g., MVC, MVP, MVVM) and provide reusable foundations such as Ruby on Rails, Spring, Laravel, Django.

Framework is a standard; architecture is the structure. Architecture is defined as the top‑level structure of a software system, a systematic decision made under resource constraints that defines subsystems, modules, components, their relationships, constraints, and guiding principles.

Key aspects of architecture:

Rational decisions through systematic thinking (technology selection, solutions).

Clear system skeleton (components and modules).

Collaboration relationships among parts.

Constraints and guiding principles ensuring order, efficiency, and stability.

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

The essence of architecture is orderly restructuring of a system to meet current business needs and enable rapid expansion.

Architecture Layers and Classifications

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

Business architecture defines strategy; application architecture translates strategy into concrete modules; technical architecture provides the equipment.

Business Architecture (Strategic)

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

Application Architecture (Tactical)

Abstracts hardware to applications, defines independent deployable units, their boundaries, responsibilities, and collaboration (interfaces, protocols).

Application layering can be horizontal (web front‑end / middle services / back‑end tasks) or vertical (different business domains).

Application architecture balances business complexity and technical complexity.

Data Architecture

Guides database design, both logical models and physical storage.

Code Architecture (Development Architecture)

Provides concrete guidance for developers: configuration design, frameworks, coding conventions, module division, top‑level file structure, dependencies.

Technical Architecture

Defines runtime components (LVS, Nginx, Tomcat, PHP‑FPM) and their relationships, focusing on non‑functional requirements such as high availability, performance, scalability, and security.

Deployment Topology

Shows node distribution, high‑availability, network interfaces, and is mainly 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 (business architecture) guides overall system design; tactical design (application architecture) implements it; tactical implementation selects technologies.

Evolution of Application Architecture

From monolithic applications to distributed services to microservices, each stage addresses increasing business complexity and scalability.

Measuring Architecture Reasonableness

Good architecture serves business, balances efficiency, stability, and security, and meets both functional and non‑functional requirements such as high availability, documentation, extensibility, reusability, and safety.

Common Architecture Pitfalls

Ignoring key constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making premature critical decisions.

Relying solely on large‑company solutions.

Prioritizing technology over business needs.

Recommended Architecture Books

Large‑Scale Website Architecture: Core Principles and Case Studies

Billions‑Level Traffic Website Architecture Core Technologies

Architecture Is the Future

Distributed Service Architecture: Principles, Design, and Practice

Chat About Architecture

The 12 Disciplines of a Software Architect