什么叫网站维护百度云服务器官网
目录
一线架构师: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大原则。
- 职责分离原则
- 通用专用分离原则
- 技能分离原则
- 工作量均衡原则
架构，是一种递进的能力。