一线架构师实践指南--笔记

 
----------------------------------------------------------------------------------------------------------------------------------

机制

引入

机制是设计的灵魂所在......否则我们就将不得不面对一群无法相互协作的对象，他们相互推搡着做自己的事情而毫不关心其他对象。

定义

软件系统中的机制，是指预先定义好的、能够完成预期目标的、基于抽象角色的协作方式。机制不仅包含了协作关系，同时也包含了协作流程。

协作：多个对象为完成某中目标而进行的交互

总结：机制是一个特殊的子系统，在实现不同的最终功能时，可以重用同一机制。例如“消息机制”。

逻辑架构：


498)this.style.width=498;"
height=444<





软件世界本无模块，划分模块是为了解决复杂性更高的大问题。对问题的分解，分别解决小问题，是手段。因此，必须把模块放在协作的平台上。所以协作决定接口。

--------------------------------------------------------------------------------------------------------------------------------------------

提纲：

划分子系统遵循四个原则的相关：职责、通用性、开发技能、工作量。

协作决定接口。

 

如何划分子系统

下面是分层的细化、分区的引入、机制的提取这3种策略背后的4个通用设计原则：

职责不同的单元划归不同子系统。

通用性不同的单元划归不同子系统。

需要不同开发技能的单元划归不同子系统。

兼顾工作量的相对均衡，进一步切分太大的子系统。

如图13-11所示，子系统的每种划分策略，都是一到多个原则综合作用的结果。

 

接口设计的事实与谬误

世界是复杂的，很多东西难以直接获得。例如，直接追求幸福，是永远追不到的。（《乐在工作》一书中说幸福是副产品。）

殊不知，合理的接口设计也不是"直接"得到的。

由于面向对象非常强调"自治"，许多人不知不觉地形成了一种错误认识：面向对象推崇"我的接口我做主"。很遗憾，"自治"正确，但"我的接口我做主"这个推断是错误的。

软件世界中本无模块。1968年，Dijkstra发表了第1篇关于层次结构的论文《The Structure of THE-multiprogramming System》。1972年，Parnas发表论文《On the criteria To Be Used in Decomposing System into Modules》论及了模块化和信息隐藏的话题……这些是架构学科开始萌芽的标志。

那么，为什么要对软件进行模块化设计呢？是为了解决复杂性更高的大问题。于是，我们突然领悟：对问题进行分解，分别解决小问题，其实这只是手段。每个架构师应牢记：

"分"是手段，"合"是目的。不能"合"在一起支持更高层次功能的模块，又有何用呢？

因此，我们必须把模块放在协作的上下文之中进行考虑。架构师设计接口时，要考虑的重点是"为了实现软件系统的一系列功能，这个软件单元要和其他哪些单元如何协作"，总结成一句话就是：协作决定接口。

相反，直接设计接口，是很多"面向接口的"架构依然拙劣的原因之一。类似"我的接口我做主"的观点是错误的（如图13-12所示），每个模块或子系统（甚至类）无视协作需要而进行的接口定义很难顺畅地被其他模块或子系统使用。

"世界上最短的距离不是直线"，又多了一个例证。

 

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

逻辑架构设计的10条经验
 
划分子系统：分层的细化
划分子系统：分区的引入
划分子系统：机制的提取
接口的定义：协作决定接口
选用序列图：杜绝协作图（专注于于行为设计，协作图结构气太重）
包-接口图：从结构到行为的桥
灰盒包图：描述子系统
循序渐进的螺旋思维
设计模式：包内结构
设计模式：包间协作

一线架构师实践指南——原书
贯穿案例

下面，继续本书的贯穿案例：PASS系统的架构设计。首先应注意两点：
 

第一，细化架构设计的重要"输入"之一是概念架构设计，不应忽视，毕竟细化架构设计是整个架构设计过程中的一个阶段。例如，在第9章进行的"基于鲁棒图的初步设计"，以及第9章进行的高层分割考虑（如图13-29所示）。

第二，5视图方法的运用，总体而言是5个视图的设计穿插进行的，对复杂系统而言，根本不可能将逻辑视图设计完全之后再考虑其他视图。而本例的PASS系统具有很强的分布特点，所以必然较早地考虑到物理视图对逻辑设计的影响。例如，PASS服务器作为一个物理架构元素的"节点（Node）"，它之上"跑"的逻辑架构元素"逻辑层（Layer）"有哪些呢？如图13-30所示，它包含了业务层、集成层、数据访问层，但未包括展现层程序。

进入细化架构阶段的逻辑架构设计，常以初步设计为基础，借助分层细化、分区引入、机制提取等手段。如图13-31所示，对PASS服务器软件进行逻辑架构的结构设计。

从结构设计跳到行为设计，常用手段是画序列图。图13-32是"实时检查处方功能"的序列图--它处在逻辑架构设计的"螺旋式"整体思维套路的起始循环，是进一步深入设计的基础。

有了不同职责单元之间具体的协作关系，就可以展开细致的"质疑"了--别忘了，架构设计是质疑驱动的（相关标注同样显示在图13-32上）。

处方检查服务能被医生工作站访问到吗？毕竟前者位于PASS服务器上……于是，设计中要进一步明确"远程调用机制"。

这样一个分布式的系统，访问服务之前要经过什么样的验证呢……于是，进一步考虑安全性的支持。

不同的医生不停地开处方，处方检查功能会不会很慢？常用药的用药规则应该常驻内存，这样才能提升性能……于是，设计中要进一步明确Cache等提升性能的机制。

……

于是，自然而然地，沿着逻辑架构设计的"螺旋式"整体思维套路思考，我们就能意识到"结构设计"要继续完善和细化。基于对远程调用、安全性、高性能的质疑，改进"结构设计"后就得到如图13-33所示的逻辑架构图。