Understanding Software Architecture: Concepts, Layers, and Evolution

1. What Is Architecture and Its Essence

In the software industry, the term "architecture" is often debated. Before discussing architecture, it is essential to define its concept, which serves as a basis for communication.

Examples of architecture include Linux, MySQL, and the JVM. Related concepts include system vs. subsystem, module vs. component, and framework vs. architecture.

1.1 System and Subsystem

System: a group of related entities that work together to achieve capabilities that individual elements cannot.

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

1.2 Module and Component

Modules are logical units; components are physical units.

A module can be a system, a set of subsystems, a service, a class, a method, etc.

Components may include services, databases, networks, physical machines, MQ, containers, Nginx, etc.

1.3 Framework vs. Architecture

Frameworks are specifications for implementing components (e.g., MVC, MVP, MVVM) and provide base functionality (e.g., Ruby on Rails, Spring, Laravel, Django). Architecture is the top‑level structure of a software system, representing the most reasonable decisions made under resource constraints.

Architecture involves systematic thinking, rational decisions, a clear system skeleton (subsystems, modules, components), collaboration relationships, constraints, and guiding principles.

2. Architecture Layers and Classifications

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

2.1 Business Architecture

Defines business planning, modules, processes, and domain models, turning real‑world business into abstract objects.

2.2 Application Architecture

Describes how applications (logical modules or subsystems) are organized, their boundaries, responsibilities, and collaboration. It includes two key aspects:

Responsibility division – logical layering, subsystem/module definition, key classes.

Collaboration – interface protocols and inter‑application call relationships.

Application layering can be horizontal (e.g., web front‑end, middle services, background tasks) or vertical (e.g., separate applications for inventory, sales, etc.).

2.3 Data Architecture

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

2.4 Code Architecture (Development Architecture)

Provides concrete guidance for developers, defining code units, organization, coding standards, module division, top‑level file structure, and dependency relationships.

2.5 Technical Architecture

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

2.6 Deployment Topology

Shows the physical nodes, their connections, high‑availability setups, network interfaces, and protocols, which are primarily of interest to operations engineers.

3. Architecture Levels

System level – relationships and governance across the whole system.

Application level – overall structure of a single application and its interaction with other applications.

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

Code level – ensuring the architecture is enforced through code.

4. Evolution of Application Architecture

4.1 Monolithic Applications

Typical three‑tier structure (frontend + business logic + database). Suitable for simple, early‑stage business needs.

Drawbacks include high complexity, technical debt, low deployment frequency, reliability issues, limited scalability, and difficulty adopting new technologies.

4.2 Distributed (Service‑Oriented) Architecture

Splits the system into independent services based on business modules, improving coupling, clarity of responsibility, scalability, and deployment flexibility, while introducing remote communication overhead.

4.3 Microservices

Further decomposes services into fine‑grained, business‑focused units, offering easier development, fast startup, isolated deployment, and technology‑stack flexibility. However, it brings higher operational demands, distributed complexity, API change costs, and potential code duplication.

5. Measuring Architectural Reasonableness

5.1 Business‑Driven Criteria

Ability to solve current business problems efficiently.

Scalable design that remains suitable for future growth.

5.2 Non‑Business Criteria

Stability – high availability, thorough testing.

Efficiency – documentation, extensibility, reusability.

Security – data protection, encryption, HTTPS.

6. Common Architectural Pitfalls

Ignoring key constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making premature critical decisions.

Relying solely on stakeholder demands without technical insight.

Lacking foresight and measurability.

Attempting to achieve a perfect architecture in one step.