Mastering Software Architecture: Methodologies, Principles, and Patterns

Architecture Methodologies

Software architecture includes Procedure‑Oriented, Object‑Oriented, Component‑Oriented, Aspect‑Oriented, and Service‑Oriented approaches. Each focuses on different concerns and evolves with software engineering and system scale. The choice depends on the scenario and appropriate technology selection.

Procedure‑Oriented Programming

Core idea: functional decomposition (top‑down). Break a large problem into smaller sub‑problems, solving the smallest ones first.

Formula: Program = Algorithm + Data Structure Focus: flow, functions, libraries. Advantages: straightforward, easy to understand. Disadvantages: tightly coupled with business process, low reusability. Typical languages: BASIC, C.

Object‑Oriented Programming

Objects combine algorithm and data structure. Formula: Object = (Algorithm + Data Structure), Program = Object + Object + … Focus: abstraction, classes, inheritance, encapsulation, polymorphism. Advantages: reusability, extensibility, flexibility, maintainability. Disadvantages: can over‑complicate simple problems, does not address cross‑cutting concerns. Typical languages: Java, C#.

Methodologies: OOA (Object Oriented Analysis), OOD (Object Oriented Design), OOP (Object Oriented Programming).

Component‑Oriented Programming

Enables reuse of multiple classes or whole programs (components). Formula: Program = Component + Interaction. Focus: functional modules. Advantages: higher reuse through componentization. Disadvantages: increased maintenance and upgrade cost. Typical framework: OSGi.

Aspect‑Oriented Programming

Separates cross‑cutting concerns into aspects, allowing many classes to share behavior that can be changed centrally.

Key concepts: aspects, advice, join points, weaving. Implementation: dynamic proxies. Typical framework: Spring AOP.

Service‑Oriented Programming

Targets loose coupling between service providers and consumers. A service is a unit that delivers a result to a consumer.

Analogy: a CD player provides a playback service regardless of the specific device.

Key characteristics: loose coupling, location transparency, protocol independence. Formula: System = Service + Interaction. Focus: serviceization, business decomposition, independent deployment, service granularity. Evolution: RPC, service frameworks, governance, micro‑services. Advantages: reusable business components, better resource utilization. Disadvantages: higher maintenance and deployment cost, requires automation. Typical frameworks: Dubbo, ZeroIce, Spring Boot.

System Decomposition

Complex systems are split into smaller systems, then modules, based on requirements analysis. Decomposition can be vertical (by business domain) or horizontal (by layers).

Vertical Decomposition

Divides into system, subsystems, modules, functions, interfaces.

Horizontal Decomposition

Physical: separate layers deployed together (e.g., access, service, resource layers). Logical: logical layers such as presentation, business, resource organization layers.

Design guideline: each layer has its own boundaries, responsibilities, and depends only on lower layers to avoid cross‑layer calls.

Basic Architectural Principles

Scenario‑driven design

Abstraction

High cohesion

Loose coupling

Separation of concerns / responsibilities

Layered architecture

General‑purpose vs. specialized components

Balance and trade‑offs (no perfect architecture)

SOLID principles

Patterns

Patterns provide reusable solutions to recurring problems. Three categories are covered:

Design Patterns

Creational (5): Factory Method, Abstract Factory, Singleton, Builder, Prototype.

Structural (7): Adapter, Decorator, Proxy, Facade, Bridge, Composite, Flyweight.

Behavioral (11): Strategy, Template Method, Observer, Iterator, Chain of Responsibility, Command, Memento, State, Visitor, Mediator, Interpreter.

Architecture Patterns

Examples: Layered, Blackboard, Pipes/Filters, Broker, MVC, PAC, Reflection, Microkernel, etc.

Infrastructure Patterns

Address hardware, network, middleware, security, and other low‑level concerns. See the book “Infrastructure Design Patterns” for details.

Architecture Views

The 4+1 view model presents the system from different stakeholder perspectives.

Logical view – defines responsibilities and collaborations.

Development view – describes program units, source files, libraries, project structure.

Data view – specifies stored data and formats (files, relational or real‑time databases).

Physical view – outlines physical nodes, topology, hardware, and software selection.

Process view – details control flow, processes, threads, services, startup/shutdown, communication, synchronization.

Summary

The article introduced architecture methodologies, system decomposition, fundamental principles, common patterns, and the 4+1 view model, providing a comprehensive overview for purposeful learning of software architecture.