Mastering Software Architecture: From Basics to Evolution

What Architecture Is and Its Essence

In the software industry, the term "architecture" is often debated; a clear definition is essential for effective communication. Architecture can be found at many levels—Linux, MySQL, JVM, and any business system built on these components. Understanding related concepts such as system vs. subsystem, module vs. component, and framework vs. architecture is crucial.

System vs. Subsystem : A system is a group of interrelated entities that together achieve capabilities none can accomplish alone; a subsystem is a system that exists within a larger system.

Module vs. Component : Modules are logical units that decompose a system, while components are physical units (e.g., services, databases, networks, containers).

Framework vs. Architecture : Frameworks provide reusable conventions (e.g., MVC, Spring), whereas architecture defines the overall structure and constraints.

Software architecture is the top‑level structure of a software system, a systematic, rational decision made under resource constraints that defines the system skeleton—subsystems, modules, components, their interactions, constraints, and guiding principles.

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 system design; technical architecture selects the concrete runtime components (e.g., Nginx, Tomcat) and addresses non‑functional requirements such as high availability and performance.

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 design, data and state management.

Code level : Guarantees that the architecture is realized in code.

Strategic vs. Tactical Design

Strategic design (business architecture) guides how architects should approach system design. Tactical design (application architecture) refines the strategy into concrete solutions, and tactical implementation selects the appropriate technology stack.

Application Architecture Evolution

Architecture evolves from monolithic applications to distributed services and finally to micro‑services.

Monolithic Applications

Early projects often use a three‑tier structure (frontend + business logic + database) implemented with frameworks like Spring MVC or Django. While easy to deploy, monoliths become hard to maintain as codebases grow, leading to high complexity, technical debt, low deployment frequency, reliability issues, limited scalability, and hindered innovation.

Complexity grows with millions of lines of code.

Technical debt accumulates as requirements change.

Full‑stack redeployments become time‑consuming.

Single points of failure affect the entire system.

Scaling requires over‑provisioning hardware.

Introducing new technologies is difficult.

Distributed Systems

When business functionality expands, splitting the system into independent services reduces coupling, clarifies responsibilities, eases scaling, and simplifies deployment. However, it introduces operational overhead, distributed complexity, and higher interface maintenance costs.

Reduced coupling via service interfaces.

Clear ownership of sub‑projects.

Easy addition of new features.

Flexible deployment.

Improved code reuse.

Increased effort for remote communication.

Micro‑services

Micro‑services focus on single business capabilities, enabling faster development, independent deployment, and technology‑stack flexibility. Challenges include higher operational demands, distributed system complexity, API change costs, and potential code duplication.

Easy development and maintenance of small services.

Fast startup times.

Localized deployments.

Freedom to choose different tech stacks per service.

Measuring Architectural Reasonableness

A good architecture balances business needs and non‑functional requirements. Evaluation criteria include:

Business perspective : solves current problems efficiently, offers reusable solutions, and remains forward‑compatible.

Non‑business perspective : high availability, comprehensive documentation, scalability, reusability, and security.

Common Architectural Pitfalls

Ignoring key 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 focusing only on immediate implementation.

Neglecting testability.

Attempting to achieve a perfect design in one step.

Architecture Knowledge System

The knowledge system covers evolution stages, patterns, and core elements such as performance, availability, scalability, and security.

Evolution : LAMP → separate app/database servers → caching → clustering → read/write separation → CDN → distributed files/databases → service decomposition.

Patterns : layered (application, service, data), vertical splitting, distributed services, distributed static resources, distributed data/storage, distributed computing.

Core Elements :