一线架构师实践 内置最佳实践

方法不应该是个空框框，应融入最佳实践经验。相信业界很多专家都正朝着这个方向迈进。

ADMEMS方法中融入了笔者的哪些实践经验呢？仅举几例：

逻辑架构设计的10条经验（如图1-3所示）。

质疑驱动的逻辑架构设计整体思路（如图1-4所示）。

基于鲁棒图进行初步设计的10条经验。

ADMEMS矩阵方法。

约束的4大类型。

……

  图1-3  逻辑架构设计的10条经验

  图1-4  质疑驱动的逻辑架构设计整体思路

 

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

1.3  ADMEMS方法体系：3个阶段，1个贯穿环节

作为方法体系，ADMEMS方法通过3个阶段和1个贯穿环节，来覆盖"需求进，架构出"的架构设计完整工作内容。

图1-5说明了"3个阶段"在整个方法体系中的位置。具体而言：

预备架构（Pre-architecture）阶段（简称PA阶段）。

最大误区：架构师是技术人员不必懂需求。

实践要点：摒弃"需求列表"方式，建立二维需求观。

思维工具：ADMEMS矩阵等。

概念架构（Conceptual Architecture）阶段（简称CA阶段）。

最大误区：概念架构 = 理想设计。

实践要点：重大需求塑造概念架构。

思维工具：鲁棒图、目标-场景-决策表等。

细化架构（Refined Architecture）阶段（简称RA阶段）。

最大误区：架构 = 模块 + 接口。

实践要点：贴近实践的5视图法。

思维工具：包图、包-接口图、灰盒包图、序列图、目标-场景-决策表等。

  图1-5  ADMEMS方法体系包含3个阶段

值得强调的是，上述3个阶段之间的先后顺序有极大的实际意义，否则就不能称其为"阶段"了：

试想，在Pre-architecture阶段对需求理解不全面（例如遗漏了需求）、不深入（例如没有发现"高性能"和"可扩展"是两个存在矛盾的质量属性），后续设计怎会合理？

试想，Conceptual Architecture阶段的概念架构设计成果没有反映系统的特点就"冲"去做Refined Architecture设计，是不是必然造成更多的设计返工？

"1个贯穿环节"，指的是对非功能目标的考虑。

 

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

1.3.1  Pre-architecture阶段：ADMEMS矩阵方法

Pre-architecture阶段的使命，可以概括为一句话：全面理解需求，从而把握需求特点，进而确定架构设计驱动力。其中，ADMEMS矩阵居于方法的核心。

"ADMEMS矩阵"又称为"需求层次-需求方面矩阵"（如表1-1所示），帮助架构师告别需求列表的陈旧方式，顺利过渡到二维需求观，借此避免遗漏需求、并进一步理清需求间关系和发现衍生需求。

表1-1  ADMEMS矩阵的基础是二维需求观

 

功能

质量

约束

业务级需求

业务目标

快、好、省

技术性约束

 

法规性约束

 

技术趋势

 

竞争因素与竞争对手

遗留系统集成

标准性约束

分批实施

用户级需求

用户需求

运行期质量

用户群特点

用户水平

多国语言

开发级需求

行为需求

开发期质量

开发团队技术水平     

开发团队分布情况     

管理：保密要求       

安装                 

开发团队磨合程度

开发团队业务知识

管理：产品规划

维护

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

1.3.2  Conceptual Architecture阶段：重大需求塑造做概念架构

概念架构 ≠ 理想化架构。所以，必须考虑包括功能、质量、约束在内的所有方面的需求。图1-6说明了ADMEMS方法推荐的概念架构设计的高层步骤。

  图1-6  ADMEMS方法推荐的概念架构设计做法

 

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

1.3.3  Refined Architecture阶段：落地的5视图方法

细化架构是相对于概念架构而言的。细化架构阶段的总体方法为5视图方法，如图1-7所示。

  图1-7  5视图法：ADMEMS方法的一部分

许多架构师，言架构则必谈OO。在他们的思想里，认为OO方法已完整涵盖了架构设计的所有方法和技巧。这种看法是相当片面的。

分析图1-7。若OO方法已涵盖架构设计的全部，那么5视图方法所涉及的逻辑架构、物理架构、开发架构、运行架构、数据架构，都应全面受到OO方法的指导，然而实际上并不是这样。正如图中所标明的，物理架构、开发架构、运行架构和数据架构这4个架构视图，分别是面向节点、面向文件、面向控制流和面向Table（或文件）的--也就是说，一般认为这4个架构视图主要的思维并非OO思维。另一方面，即使是逻辑架构的设计，也未必都是以OO方法为指导的。例如，大量嵌入式软件和系统软件还是以C语言为主要开发语言，其逻辑架构设计会以结构化方法为指导。如此看来，倒是将逻辑架构设计总结为"面向职责"更贴近本质。

 

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

1.3.4  持续关注非功能需求："目标-场景-决策"表方法

非功能需求不可能是"速决战"，连编码都会影响到性能等非功能属性，更何况概念架构设计和细化架构设计。

作为ADMEMS方法应对非功能需求的思维工具，目标-场景-决策表将架构师的思维可视化了。例如，如表1-2所示的目标-场景-决策表，揭示了大型网站高性能设计策略背后的理性思维。

表1-2  目标-场景-决策表：揭示大型网站高性能设计策略背后的理性思维

目标

场   景

决   策

性能

Ÿ       客户端，重复请求页面，Web服务器请求数多负载压力大

代理服务器

Ÿ       客户端，重复请求页面，页面生成逻辑重复执行

Html静态化

Ÿ       客户请求，来自不同ISP，页面跨网络传递慢

内容分发网络

Ÿ       客户端，大量请求图片资源，Web服务器压力大

Ÿ       客户端，大量请求图片资源，Web服务器无法专门优化

图片服务器

Ÿ       程序，大量申请数据，硬盘IO压力大

Ÿ       程序，申请不同数据，DBMS缓存低效

数据库拆分

Ÿ       （环境：部署多个DBMS实例）

程序，更新数据，数据复制开销大

数据库读写分离

 

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

1.4  如何运用本书解决"6大困惑"

至此，我们已走马观花地了解了本书要讲的ADMEMS方法的特点。那么，如何运用本书解决章首提到的"6大困惑"呢？

如图1-8所示，针对6个困惑分别给出了阅读路线图。

  图1-8  针对6个困惑，不同的阅读路线图

例如，如果你是一个已有一定实践经验的架构师，希望更加合理地对系统进行模块切分，请关注"第3部分 Refined Architecture阶段"。你将了解到，划分子系统的4大原则（如图1-9所示）：

职责分离原则。

通用专用分离原则。

技能分离原则。

  图1-9  第3部分Refined Architecture阶段：划分子系统的4大原则

其他问题的解决思路在此不再展开叙述，请大家参照"路线图"阅读相应章节。

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