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

目录

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

多阶段还是多视图?

内置最佳实践

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

Pre-architecture阶段:ADMEMS矩阵方法

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

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

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

解决方案:如何解决“6大困惑”?


 

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

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第1张图片

多阶段还是多视图?

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第2张图片

 

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

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

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

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

 

内置最佳实践

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

ADMEMS方法融入了哪些实践?

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第3张图片

 转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第4张图片

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

 

 

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第5张图片

 

上面的图基本上说明“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矩阵居于方法的核心。

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第6张图片

 

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

概念架构 ≠ 理想化架构

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

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第7张图片

 

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

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

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第8张图片

 

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

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

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

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

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

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

ADMEMS方法应对非功能需求的思维工具,目标-场景-决策表可以将架构师的思维可视化出来。转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第9张图片

解决方案:如何解决“6大困惑”?

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第10张图片

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

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

转载:【成为架构师课程系列】一线架构师:6个经典困惑及其解法_第11张图片

 

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

 

你可能感兴趣的:(java,面试,开发语言)