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

01 What Is Architecture and Its Essence

Software architecture is defined as the top‑level structure of a software system, created through systematic thinking and trade‑offs under resource constraints, encompassing subsystems, modules, components, and their collaboration, and serving as a shared mental model for the development team.

Key Concepts

System vs. Subsystem: a system is a group of related entities that together achieve capabilities none can accomplish alone; a subsystem is a part of a larger system.

Module vs. Component: modules are logical units, components are physical units; modules can be services, classes, functions, etc., while components include services, databases, networks, containers, etc.

Framework vs. Architecture: frameworks provide reusable foundations (e.g., MVC, Spring), whereas architecture defines the overall structure.

02 Architecture Layers and Classification

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

Business Architecture (Strategic)

Defines business planning, modules, and processes, translating real‑world business into abstract models.

Application Architecture (Tactical)

Describes logical decomposition of applications, their boundaries, responsibilities, and interaction protocols (e.g., interfaces, APIs).

Data Architecture

Guides database design, including logical models and physical storage considerations.

Code Architecture

Specifies code units, organization, coding standards, module division, top‑level file structure, and dependency management.

Technical Architecture

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

Deployment Topology

Shows physical node layout, high‑availability configurations, network interfaces, and hardware choices, primarily of interest to operations engineers.

03 Levels of Architecture

System level – overall relationships and governance.

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

Module level – internal modular design, data, and state management.

Code level – concrete implementation details ensuring architectural compliance.

04 Evolution of Application Architecture

Progresses from monolithic applications to distributed services and finally to micro‑services, each stage addressing increasing business complexity and scalability requirements.

Monolithic

Simple three‑tier structure (Web/Client → Business Logic → Database) suitable for early‑stage projects but suffers from high complexity, low maintainability, and deployment bottlenecks as it grows.

Distributed

Splits business functions into independent services deployed on separate servers, reducing coupling, clarifying responsibilities, and improving scalability, though it introduces network overhead and interface management.

Micro‑services

Further decomposes services into fine‑grained, independently deployable units, enabling technology‑stack diversity, rapid iteration, and isolated failures, while increasing operational complexity and the need for robust inter‑service contracts.

05 Measuring Architectural Rationality

Architecture should be evaluated from business and non‑business perspectives, focusing on stability, efficiency, documentation, extensibility, reusability, and security.

Business Perspective

Solves current business problems effectively.

Provides elegant, reusable solutions.

Offers forward‑looking designs that remain viable as the business evolves.

Non‑Business Perspective

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

Efficiency: thorough documentation of lifecycle changes.

Scalability: low coupling, proper abstraction, and support for future extensions.

Reusability: avoid duplicated effort by sharing components.

Security: protect data via encryption, HTTPS, and other safeguards.

06 Common Architectural Pitfalls

Ignoring critical constraints and non‑functional requirements.

Over‑designing for an uncertain future.

Making premature critical decisions.

Following client demands blindly without technical justification.

Lacking foresight and measurement of system testability.

Attempting to achieve perfect architecture before implementation.

07 Architecture Knowledge System

Describes the evolution from LAMP monoliths to layered, distributed, and micro‑service architectures, covering patterns such as horizontal/vertical layering, clustering, caching, CDN, asynchronous messaging, redundancy, and automation for deployment, testing, monitoring, and fault recovery.