Understanding Software Architecture: Concepts, Layers, Types, Evolution, and Common Pitfalls

1. What Is Architecture and Its Essence

In the software industry, there is much debate about what architecture means, and different people have different understandings. Before discussing architecture, we must first define its concept, because concepts are the basis for communication; differing definitions lead to communication problems.

Linux, MySQL, and the JVM each have their own architecture, as does a business system built with Java on MySQL running on Linux. To clarify which architecture to focus on, we need to distinguish related concepts: system vs. subsystem, module vs. component, framework vs. architecture.

1.1 System and Subsystem

System: a group of related entities that operate according to certain rules to achieve capabilities that individual elements cannot accomplish alone.

Subsystem: also a group of related entities, usually a part of a larger system.

1.2 Module and Component

Both are parts of a system, viewed from different angles. A module is a logical unit, while a component is a physical unit.

Modules break the system down logically (divide‑and‑conquer) and can vary in granularity – from an entire system, several subsystems, a service, a class, a method, etc.

Components may include application services, databases, networks, physical machines, as well as technical components such as MQ, containers, Nginx, etc.

1.3 Framework and Architecture

A framework is a specification for implementing components, e.g., MVC, MVP, MVVM, and provides ready‑made products such as Ruby on Rails, Spring, Laravel, Django, which can be used directly or extended.

Framework is a specification; architecture is the structure.

My definition: software architecture is the top‑level structure of a software system. It is the most reasonable decision made after systematic thinking and trade‑offs under resource constraints, defining the system skeleton (subsystems, modules, components) and their collaboration, constraints, and guiding principles, thereby aligning the whole team’s mindset.

Therefore, an architect should be able to understand the business, have a global view, choose appropriate technologies, solve key problems, and guide implementation.

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

When should we consider architecture design? Architecture evolves driven by business needs, not arbitrarily.

Architecture design is purely for business.

Complex requirements

Important non‑functional requirements

Long system lifecycle with scalability needs

Component‑oriented integration needs

Business process re‑engineering needs

2. Architectural Layers and Classifications

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

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

Understanding business leads to a business architecture, which then informs an appropriate application architecture, and finally the technical architecture is implemented.

How to choose the right application architecture for current needs and ensure smooth future transitions is a key concern for developers and architects.

2.1 Business Architecture (Overview Architecture)

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; all design principles must ultimately solve business problems. Over‑design detached from business leads to pitfalls.

Reasonable architecture should anticipate business growth for 1‑2 years, allowing cost‑effective technical leadership of business growth.

2.2 Application Architecture (Logical Architecture Diagram)

Abstracts from hardware to application, including abstraction layers and programming interfaces. Application architecture and business architecture complement each other; each business part has a corresponding application part.

Example:

Application architecture defines which applications exist, their boundaries, and how they cooperate. It clarifies responsibilities, module definitions, and key classes.

Cooperation includes interface protocols (external APIs) and interaction relationships (calls between applications).

Application layering can be horizontal (by function: web front‑end, middle services, back‑end tasks) or vertical (by business domain). Horizontal layering reduces coupling, vertical layering isolates business domains.

Application design balances business complexity (splitting) and technical complexity (integration), aiming for a system that is ordered yet flexible.

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; insufficient code architecture leads to chaotic overall design, especially when different teams use different tech stacks.

Code architecture defines:

Configuration design

Frameworks and libraries

and organizes code units:

Coding conventions and habits

Project module division

Top‑level file structure (e.g., MVC)

Dependency relationships

2.5 Technical Architecture

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

Technical architecture focuses on non‑functional attributes such as high availability, performance, scalability, security, and simplicity.

2.6 Deployment Topology (Physical Architecture)

Shows how many nodes are deployed, their relationships, high‑availability setups, network interfaces, and protocols. This is primarily of interest to operations engineers.

Physical architecture considers hardware choices, topology, and the mapping between software and hardware.

3. Architectural Levels

Using a pyramid, higher levels contain lower ones:

System level : relationships among all parts and governance (layering).

Application level : overall architecture of a single application and its interaction with other applications.

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

Code level : ensuring architectural implementation at the code level.

Strategic Design vs. Tactical Design

Based on the architectural pyramid, strategic system design and tactical implementation complement each other:

Strategic design : business architecture guides how to design the system architecture.

Tactical design : application architecture follows the business architecture.

Tactical implementation : after the application architecture is fixed, technology selection occurs.

4. Evolution of Application Architecture

Business architecture is the production force, application architecture is the production relationship, and technical architecture provides the tools. Business architecture determines application architecture, which must adapt as business evolves, and finally relies on technical architecture for implementation.

Evolution path: monolithic → distributed services → micro‑services.

4.1 Monolithic Application

When a business is simple, a single‑tier application (frontend + business logic + database) suffices, e.g., a Java Spring MVC or Python Django app.

Non‑functional improvements for monoliths include caching, clustering, read/write splitting, reverse proxy/CDN acceleration, and distributed storage.

Drawbacks of monoliths (as they grow): high complexity, technical debt, low deployment frequency, reduced reliability, limited scalability, and hindered innovation.

4.2 Distributed Architecture

When business complexity grows, the system is split into independent services deployed on different servers, communicating via interfaces. Benefits include reduced coupling, clear responsibilities, easier scaling, flexible deployment, and higher code reuse. The main drawback is increased operational overhead and the need for remote communication.

4.3 Micro‑services

Complex business scenarios (pricing, inventory, orders, etc.) require fine‑grained services. Micro‑services are easy to develop and maintain, start quickly, allow localized deployment, and enable heterogeneous technology stacks.

Challenges include higher operational demands, inherent distributed complexity (fault tolerance, latency, transactions), costly API changes, and potential code duplication across services.

5. Measuring Architectural Reasonableness

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

5.1 Business‑Driven Criteria

Can solve current business needs.

Efficiently fulfills requirements with reusable solutions.

Forward‑looking design that remains valid for the foreseeable future.

5.2 Non‑Business Criteria

Stability : high availability achieved through testing, fault injection, and coverage.

Efficiency : documentation throughout the lifecycle, extensibility via low coupling, and high reuse of existing code/components.

Security : protect valuable data via encryption, HTTPS, and other standard measures.

6. Common Architectural Misconceptions

Ignoring critical constraints and non‑functional requirements.

Over‑designing for an imagined future.

Making premature critical decisions.

Being a mere messenger for customer demands.

Lacking foresight while executing.

Neglecting system testability.

Expecting a perfect, one‑shot design.

7. Architecture Knowledge System

7.1 Architecture Evolution

LAMP on a single server.

Separate application and data servers.

Introduce caching.

Adopt clustering for concurrency.

Read/write splitting.

Reverse proxy and CDN acceleration.

Distributed file and database.

Business splitting.

Distributed services.

7.2 Architecture Patterns

Layering (horizontal): application layer, service layer, data layer.

Segmentation (vertical): split functions and services.

Distributed: applications, static resources, data/storage, computation.

Clustering improves concurrency and availability.

Caching optimizes performance (CDN, reverse proxy, local cache, distributed cache).

Asynchrony reduces coupling and improves responsiveness.

Redundancy (cold/hot standby) ensures availability.

Automation covers release, testing, deployment, monitoring, alerting, failover, and recovery.

Security addresses XSS, SQL injection, CSRF, web‑firewall vulnerabilities, SSL, etc.

7.3 Core Architectural Elements

Performance: testing, front‑end optimization, application optimization, database optimization.

Availability: load balancing, data backup, automated and gray releases, monitoring and alerts.

Scalability: clustering, rapid capacity expansion.

Extensibility: open‑closed principle, low coupling.

Reliability: distributed messaging, service‑orientation.

Security: protection against attacks and vulnerabilities.

8. Recommended Architecture Books

1. "Large‑Scale Website Architecture: Core Principles and Case Studies" – A comprehensive, easy‑to‑understand guide for large‑scale web architecture.

2. "Core Technologies for Billion‑Scale Traffic Websites" – Details low‑level techniques such as caching, queues, thread pools, and includes sample code.

3. "Architecture Is the Future" – Explores the root causes of architectural problems and how to manage teams and processes.

4. "Distributed Service Architecture: Principles, Design, and Practice" – Covers design and best practices for reliable, production‑grade distributed services.

5. "Talking About Architecture" – Discusses business splitting, the purpose of architecture, the role of architects, and practical implementation.

6. "12 Practices for Software Architects" – Emphasizes soft skills and how to overcome the so‑called "technical glass ceiling".