方法不应该是个空框框,应融入最佳实践经验。相信业界很多专家都正朝着这个方向迈进。
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大原则 |
其他问题的解决思路在此不再展开叙述,请大家参照"路线图"阅读相应章节。
---------------------------------------------------------------------------------------------------------------------