Understanding System Architecture: Logical, Physical, and the 5‑View Method with Six Implementation Steps

If someone asks you to describe the architecture of your system, where would you start? Different roles have different perceptions: product managers talk about user, marketing, and product centers; developers mention three‑tier architecture and the SSM framework; users simply refer to front‑end, back‑end, and basic functions.

In practice, an architect must balance functional requirements with usability, performance, scalability, and maintainability, considering business goals, team size, developer expertise, schedule, and budget. Architecture is not static; it evolves with changing business needs while supporting those changes.

A complex system involves many participants, so the architect must make the design understandable for each role—users provide requirements, project managers plan, developers implement—ensuring clear communication, documentation, and hand‑off.

Most Common Architecture Views: Logical and Physical

Logical Architecture

Logical architecture defines the logical elements (layers, functional subsystems, modules) and their relationships.

Physical Architecture

Physical architecture shows deployment logic, how data is generated, where computation occurs, how storage and sharing are handled in the computer environment.

At the early design stage, avoid excessive technical details; focus on understanding requirements, identifying implementation challenges, and prioritizing quality versus speed.

5‑View Method: Logical, Physical, Data, Development, Runtime

Different stakeholders need different views: business diagrams for leadership, technical diagrams for developers, and operational diagrams for ops teams.

Logical Architecture

Logical architecture = module division + interface definition (standardized) + domain model.

Physical Architecture

Physical architecture = hardware distribution + software deployment + solution optimization (scalability, performance, maintainability, monitoring).

Physical architecture focuses on infrastructure such as servers, networks, and how to achieve high availability and scalability, e.g., supporting 100,000 concurrent users and adjusting resources as load changes.

Data Architecture

Data architecture = storage method + data distribution.

It concerns data persistence, storage performance, high availability, disaster recovery, and may involve relational databases or NoSQL solutions, often tightly linked with physical architecture.

Development Architecture

Development architecture = technology selection + code organization + compilation relationships (module dependencies).

It covers the entire software stack, including SDKs, third‑party libraries, and middleware, and is closely related to logical architecture.

Runtime Architecture

Runtime architecture = physical architecture + data flow control during system operation.

It addresses runtime concerns such as concurrency, thread synchronization, deadlocks, and lifecycle management.

Six Steps to Implement Architecture Design

Requirement Analysis

Collect business background, functional and non‑functional requirements, constraints (time, budget, feasibility, risk), and produce a refined requirement document.

Identify Key Requirements

Prioritize functional and non‑functional requirements that are critical to the architecture, such as high performance or scalability, while balancing cost and schedule.

Conceptual Architecture Design

Make four key decisions: top‑level subsystem division, architectural style (C/S or B/S), technology stack (e.g., Java), integration approach (APIs), and secondary development options.

Detailed Architecture Design

Apply the 5‑view method to flesh out logical, physical, data, development, and runtime architectures, refining each view from coarse to fine granularity.

Domain Modeling

Domain modeling translates business requirements into abstract model objects; common representations include class diagrams, state diagrams, and textual specifications. References to Domain‑Driven Design are recommended.

Architecture Validation

Build a prototype or address a technical challenge to test the architecture, conduct reviews, and iterate the design.

In summary, software architecture should be practical and elegant, focusing on meeting user needs, being acceptable to developers, and aligning with system characteristics and business evolution. Principles such as high cohesion, low coupling, and SOLID are often applied, along with various design and enterprise patterns.

Source: http://www.cnblogs.com/zhangs1986/p/8707721.html