成为架构师课程系列一线架构师:6个经典困惑及其解法

Posted 2023-03-03 禅与计算机程序设计艺术

 

目录 

一线架构师:6个经典困惑及其解法 

多阶段还是多视图？

内置最佳实践

架构方法论:3个阶段，一个贯穿 

Pre-architecture阶段：ADMEMS矩阵方法

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

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

持续关注非功能需求:“目标-场景-决策”表方法

解决方案：如何解决“6大困惑”？

---

一线架构师:6个经典困惑及其解法 

一线架构师经常面对的实践困惑，可以用下面的图来概括。其中，涉及了“4个实际问题的困惑”，以及“两个职业发展的困惑”。

多阶段还是多视图？

架构设计的多视图方法很重要，但是，架构设计方法首先当时多阶段的，其次才是多视图的。

一句话，先做后做--这叫阶段（Phase）,齐头并进--这叫视图(View)。

任何好的方法（不局限于软件领域），都必须以时间为轴来组织，因为这样才最利于指导实践。

架构设计只需要多视图方法，看上去很美，其实并不足够。实际上，大量一线架构师早已感觉到多视图方法的“不足够”。例如，想想投标：

• 一方面，投标时，需要提供和讲解《方案建议书》，其中涉及架构的内容。
• 另一方面，团队并行开发是，需要《架构设计文档》提供多方涉众使用。
• 但是，投标时将的“架构”和并行开发时做为基础的“架构”在同一个抽象层次上吗？绝不可能。前者叫“概念架构”，后者叫“细化架构”。
• 如果投标失败，细化架构根本没有必要做了。
• 结论，概念架构设计和细化架构设计，是两个架构阶段，不是两个架构视图。

内置最佳实践

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

ADMEMS方法融入了哪些实践？

• 逻辑架构设计的10条经验
• 质疑驱动的逻辑架构设计的整体思路
• 基于鲁棒图进行初步设计的10条经验
• ADMEMS矩阵方法
• 约束的4大类型
• ...

 

架构方法论:3个阶段，一个贯穿 

通过3个阶段和一个贯穿，来覆盖“需求进，架构出”的架构设计完整工作内容。

上面的图基本上说明“3个阶段”在整个方法体系中的位置。

具体而言：

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

  • 最大误区：架构师是技术人员不必懂需求
  • 实践要点：摒弃“需求列表”方式，建立二维需求观
  • 思维工具：ADMEMS矩阵等

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

  • 最大误区：概念架构 = 理想架构
  • 实践要点：重大需求塑造概念架构
  • 思维工具：鲁棒图、目标-场景-决策表等

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

  • 最大误区：架构 = 模块 + 接口
  • 实践要点：贴近实践的5视图法
  • 思维工具：包图、包-接口图、灰盒包图、时序图、目标-场景-决策表等

3个阶段之间的先后顺序是有极大实际意义，否则就不能称其为“阶段”了。

• 试想，在PA阶段对需求理解不全面（例如遗漏了需求）、不深入（例如没有发现“高性能”和“可扩展”是两个存在矛盾的质量属性），后续设计怎会合理？
• 试想，CA阶段的概念架构设计成果没有反应系统的特点就“冲”去做RA设计，是不是比如会造成更多的设计返工？

“1个贯穿”，指的是对非功能目标的考虑。

Pre-architecture阶段：ADMEMS矩阵方法

ADMEMS 是“Architectural Design Method has been Extended to Method System(将架构设计方法扩展到方法体系)”的缩写。ADMEMS并不是单一方法，而是由多个各具特点的方法组成的方法体系。

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

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

概念架构 ≠ 理想化架构。

所以，必须考虑包括功能、质量、约束在内的所有方面的需求。

下图是推荐的概念架构设计的步骤。

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

细化架构是相对于概念架构而言的。

细化架构阶段的总体方法为5视图方法。

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

弱OO方法已涵盖架构设计的全部，那么5视图方法所涉及的逻辑架构、物理架构、开发架构、运行架构、数据架构，都应受到OO方法的指导，然而并不是这样。

上面图中说提到的物理架构、开发架构、运行架构和数据架构者4个架构视图，分别是面对节点、面对文件、面对控制流和面向Table（或文件）的 -- 也就是说，一般认为这4个架构摄图主要的思维并非OO思维。

另一方面，即使是逻辑架构的设计，也未必是以OO方法为指导的。应该将逻辑架构设计总结为 “面向职责” 更贴近本质。

持续关注非功能需求:“目标-场景-决策”表方法

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

ADMEMS方法应对非功能需求的思维工具，目标-场景-决策表可以将架构师的思维可视化出来。

解决方案：如何解决“6大困惑”？

那么，如何运用本书解决之前提到的“6个困惑”呢？

如果，你是一个已经有一定实践经验的架构师，希望更加合理地对系统进行模块切分，请关注“第三部分 Refined Architecture阶段”。你将了解到，划分子系统的4大原则。

• 职责分离原则
• 通用专用分离原则
• 技能分离原则
• 工作量均衡原则

架构，是一种递进的能力。