4+1视图的理解和使用

软件架构

原文： Architectural Blueprints—The “4+1” View
Model of Software Architecture
老外的原文还是很值得一看的，互联网上的很多文章理解得都比较粗浅
什么是软件架构？面试的时候很多面试官可能会问你最近在做的项目的架构。其实这个问法很不准确，因为架构有多重表现形式，不同的人有不同的关注点。一般来说，面试官是想问你，你这个系统被分解成了多少个模块，每个模块的功能是什么，模块之间如何交互？通常这个模块是按照业务逻辑划分的，也就是一个个微服务，这时候它想知道的就是整个系统的逻辑视图。但是有时候可能他的关注点不在业务上面，比如他问你tomcat的架构，redis的架构，或者说你实现的那个服务的架构，这时候他想知道的就是服务内部的开发视图，也就是你服务的分层架构。

 it becomes clear
that their authors have struggled hard to represent more on one blueprint than it can actually express. Are
the boxes representing running programs? Or chunks of source code? Or physical computers? Or merely
logical groupings of functionality? Are the arrows representing compilation dependencies? Or control
flows? Or data flows? Usually it is a bit of everything

Often also the
architecture does not address the concerns of all its “customers” (or “stakeholders” as they are called at
USC)

As a remedy, we propose to organize the description of a software architecture using
several concurrent views, each one addressing one specific set of concerns.

软件架构天然的复杂性，以及不同人对架构的关注点不一样，导致一个单一的架构图（或者模型）难以表达所有的信息，所以我们使用不同的视图来表达不同的关注点。

Software architecture = {Elements, Forms, Rationale/Constraints}

• The logical view, which is the object model of the design (when an object-oriented design method is
used),
• the process view, which captures the concurrency and synchronization aspects of the design,
• the physical view, which describes the mapping(s) of the software onto the hardware and reflects its
distributed aspect,2
• the development view, which describes the static organization of the software in its development
environment.

架构是什么？架构就是组成软件的元素以及元素之间的关系。
逻辑视图：元素是对象，关系是依赖，继承。。。
进程视图：元素是进程，关系是RPC调用关系以及时序
物理视图：元素是机器，关系机器的物理分布
开发视图：元素是package或者module，关系是package之间的依赖关系

关于stakeholder

逻辑视图：终端用户，表达的是功能需求
进程视图：开发者，用于服务之间的集成和性能分析
物理视图：SRE，用于部署
开发视图：开发者，软件开发和管理，比如分层架构，每个package的功能，保障软件的清晰

The Logical Architecture

The Object-Oriented Decomposition。
逻辑视图是建模的结果，表达的是业务逻辑。The logical architecture primarily supports the functional requirements—what the system should provide in
terms of services to its users.

The Process Architecture

The Process Decomposition

The process architecture takes into account some non-functional requirements, such as performance and
availability. It addresses issues of concurrency and distribution, of system’s integrity, of fault-tolerance, and
how the main abstractions from the logical view fit within the process architecture—on which thread of
control is an operation for an object actually executed

分布式系统中各个服务在完成一个请求的时候的调用关系。

The Development Architecture

Subsystem decomposition

The development architecture focuses on the actual software module organization on the software
development environment. The software is packaged in small chunks—program libraries, or subsystems—
that can be developed by one or a small number of developers

The subsystems are organized in a hierarchy
of layers, each layer providing a narrow and well-defined interface to the layers above it

We recommend adopting a layered style for the development view, defining some 4 to 6 layers of
subsystems. Each layer has a well-defined responsibility. The design rule is that a subsystem in a certain can
only depend on subsystem that are in the same layer or in layers below, in order to minimize the
development of very complex networks of dependencies between modules and allow simple release
strategies layer by layer

开发视图表示了开发者把系统划分为多少个模块。描述一个分层系统也是开发视图的职责

The Physical Architecture

Mapping the software to the hardware

Scenarios

Putting it all together
使用user story， 流程图，验证架构的合理性