What Truly Defines Software Architecture? A Deep Dive into Concepts, Layers, and Evolution

Definition of Architecture and Related Concepts

In software engineering, architecture refers to the top‑level structure of a system, representing the most reasonable decisions made after systematic analysis, trade‑offs, and resource constraints. It defines subsystems, modules, components, their collaboration, constraints, and guiding principles.

System : a collection of interrelated entities that work together to achieve capabilities none of the individual parts can provide.

Subsystem : a system that functions as a part of a larger system.

Module : a logical unit obtained by decomposing a system (e.g., services, functions, classes).

Component : a physical unit such as a service, database, network device, server, message queue, container, or reverse proxy.

A framework supplies conventions and reusable building blocks (e.g., MVC, Spring, Django). Frameworks are specifications; architecture is the overall structural design.

Software Architecture Essentials

Reasoned decisions (technology selection, solution design).

Clear system skeleton (identifying subsystems, modules, components).

Collaboration relationships (how parts interact to satisfy business requests).

Constraints, standards, and guiding principles that ensure stability, efficiency, and security.

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

Architecture Layers and Classifications

The architecture can be divided into six complementary layers:

Business Architecture : strategic view; defines business planning, modules, processes, and domain models.

Application Architecture (logical/profile architecture): bridges business and technical layers; defines applications, boundaries, and interaction protocols. It can be organized horizontally (by function) or vertically (by business domain).

Data Architecture : guides logical data modeling and physical storage design.

Code Architecture (development architecture): provides concrete guidance for developers, including code unit definitions, module organization, naming conventions, top‑level file structure, and dependency management.

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

Deployment Topology : shows node relationships, high‑availability setups, network interfaces, and protocols; primarily of interest to operations engineers.

Architecture Levels

System level : governance and relationships across the entire system.

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

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

Code level : ensuring implementation follows the architectural intent.

Strategic vs. Tactical Design

Strategic design : business architecture guides the overall system design.

Tactical design : application architecture is derived from the business architecture.

Tactical implementation : technology selection follows the application architecture.

Evolution of Application Architecture

Application architecture typically evolves from monolithic to distributed services and finally to microservices.

Monolithic Architecture

Typical three‑tier structure (frontend → business logic → database) using frameworks such as Spring MVC or Django.

Advantages: simple deployment and testing. Drawbacks: high complexity, technical debt, low deployment frequency, reliability issues, limited scalability, and hindered innovation.

Distributed (Service‑Oriented) Architecture

Systems are split into independent services deployed on separate servers and communicating via well‑defined interfaces.

Reduced coupling and clearer responsibilities.

Scalable and flexible deployment.

Introduces remote‑call overhead.

Microservices

Each microservice focuses on a specific business capability, enabling independent development, fast startup, isolated deployments, and heterogeneous technology stacks.

Pros: easier development, faster releases, technology‑stack freedom.

Cons: higher operational complexity, distributed‑system challenges (network latency, fault tolerance, distributed transactions), API change costs, and potential code duplication.

Measuring Architectural Reasonableness

Business perspective : solves current problems efficiently and provides forward‑compatible design.

Non‑business perspective : evaluates stability (high availability, testing), efficiency (documentation, extensibility, reusability), and security (encryption, HTTPS, access controls).

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 measurable design criteria.

Attempting to achieve a perfect architecture in a single step.

Architecture Knowledge System

Typical evolution stages:

LAMP on a single server.

Separation of application and data servers.

Introduction of caching.

Clustering for concurrency and availability.

Read/write database separation.

Reverse proxy and CDN acceleration.

Distributed file systems and databases.

Business splitting and distributed services.

Core patterns include layering (application, service, data), vertical splitting, and distributed designs (static resources, data/storage, compute). Supporting techniques are clustering, caching (local, CDN, distributed), asynchronous messaging, redundancy, CI/CD automation, and security hardening (XSS, SQL injection, CSRF, firewalls, SSL).