Understanding Software Architecture: Core Concepts, Layers, and Evolution

1. What Is Architecture and Its Essence

In software engineering, the term "architecture" is often debated; different people may have different definitions. Before discussing architecture, we must define its concept, which serves as the basis for communication. Linux, MySQL, and the JVM each have their own architecture, as does a business system built with Java, MySQL, and running on Linux. Understanding which architecture to focus on requires clarifying related concepts: system vs. subsystem, module vs. component, and framework vs. architecture.

1.1 System and Subsystem

A system is a group of related entities that work together under certain rules to achieve capabilities that individual parts cannot accomplish alone. A subsystem is also a group of related entities, typically 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 down complexity by logical separation; components can 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 reusable foundations such as Ruby on Rails, Spring, Laravel, Django. Architecture, on the other hand, is the structural design.

We define software architecture as the top‑level structure of a software system. It is a systematic, rational decision made under resource constraints that clarifies the system skeleton—including subsystems, modules, components, their collaboration, constraints, and guiding principles—ensuring consistent thinking across the team.

Reasoned decisions (e.g., technology selection, solution design)

Clear system skeleton (identifying parts)

Collaboration relationships among parts

Constraints and guiding principles for stability, efficiency, and reliability

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

The essence of architecture is the orderly reconstruction of a system to meet current business needs while allowing rapid expansion.

2. Architecture Layers and Classifications

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

Business architecture defines strategy; application architecture translates strategy into concrete designs; technical architecture provides the equipment (e.g., LVS, Nginx, Tomcat, PHP‑FPM) and deployment strategies. The application architecture bridges business and technical layers, defining which applications exist, their boundaries, and how they cooperate.

2.1 Business Architecture (Strategic)

Includes business planning, modules, processes, and domain modeling, turning real‑world business into abstract objects. There is no "optimal" architecture, only the most suitable one that solves business problems without unnecessary complexity.

2.2 Application Architecture (Logical)

Describes how hardware maps to applications, defining clear boundaries, responsibilities, and collaboration mechanisms (interfaces, protocols, data formats). It can be split horizontally (frontend / middle‑service / backend task) or vertically (different business domains as independent applications).

Responsibility division: logical layers, subsystem/module definitions, key classes

Collaboration: external interfaces, inter‑application call relationships

2.3 Data Architecture

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

2.4 Code Architecture (Development)

Provides concrete guidance for developers: configuration design, frameworks/libraries, coding standards, project module division, top‑level file structure, dependency management, etc.

2.5 Technical Architecture

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

2.6 Deployment Topology (Physical)

Shows node count, relationships, high‑availability setups, network interfaces, and protocols, determining how the system runs, its performance, maintainability, and extensibility. This diagram is primarily of interest to operations engineers.

3. Architecture Levels

Using a pyramid model, higher levels contain lower ones:

System level : relationships and governance across the whole system.

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

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

Code level : ensuring implementation aligns with architectural decisions.

4. Application Architecture Evolution

Business architecture drives production; application architecture provides the production relationship; technical architecture supplies the tools. As business evolves, application architecture must adapt, eventually moving from monoliths to distributed services and micro‑services.

4.1 Monolithic Applications

Suitable for simple early‑stage businesses. Typical three‑tier structure: frontend (Web/mobile) + business logic layer + database layer (e.g., Java Spring MVC or Python Django).

Non‑functional improvements include caching, clustering, read/write separation, reverse proxy/CDN, distributed files/databases. However, monoliths become complex, hard to maintain, and costly to deploy as they grow.

High complexity (large codebase, unclear boundaries)

Technical debt

Low deployment frequency

Poor reliability

Limited scalability

Hinders innovation

4.2 Distributed Applications

When business functions become numerous and complex, the system is split into services deployed on separate servers, communicating via interfaces. Benefits include reduced coupling, clear responsibilities, easier scaling, flexible deployment, and higher code reuse. Drawbacks involve increased remote‑communication overhead.

4.3 Micro‑services

Further decomposition into fine‑grained services that each handle a specific business capability. Advantages: easier development/maintenance, fast startup, localized deployments, and technology‑stack flexibility. Challenges: higher operational demands, distributed system complexity, API change costs, and potential code duplication.

5. Measuring Architectural Reasonableness

Good architecture serves business efficiently, stably, and securely. Evaluation criteria include:

5.1 Business‑Driven Metrics

Solves current business problems effectively and elegantly.

Provides forward‑looking design that remains suitable for future growth.

5.2 Non‑Business Metrics

Stability (high availability, thorough testing, fault injection).

Efficiency (documentation, extensibility, high reuse).

Security (encryption, HTTPS, protection against XSS, SQL injection, CSRF, etc.).

6. Common Architectural Pitfalls

Ignoring key constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making premature critical decisions.

Being a mere messenger for customer demands.

Lacking foresight while focusing only on implementation.

Neglecting system testability.

Attempting to achieve everything in a single step.

Additional misconceptions include believing only architects should care about architecture, thinking the blueprint alone is enough, or chasing perfection instead of incremental improvement.

7. Architecture Knowledge System

Key aspects:

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

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

Scalability: clustering, rapid addition of nodes.

Extensibility: modular design, open‑closed principle, distributed messaging and services.

Security: protection against XSS, SQL injection, CSRF, web‑firewall vulnerabilities, SSL, etc.

8. Recommended Architecture Books

"Large‑Scale Website Architecture: Core Principles and Case Studies"

"Core Technologies for Billion‑Scale Traffic Websites"

"Architecture Is the Future"

"Distributed Service Architecture: Principles, Design, and Practice"

"Talking About Architecture"

"12 Practices for Software Architects"

These resources cover both high‑level strategic thinking and detailed technical implementations.