一线架构师: 6个经典困惑
一线架构师经常 面对的实践困感，可以用图1-1来概括。其中，涉及了“4个实际问题的困惑”，以及“两个职业发展的困惑”。
4个核心主张
画龙须点睛。
在介绍具体方法之前，先来阐释本书的4个核心主张:
方法体系是大趋势。
质疑驱动的架构设计。
多阶段方法。
内置最佳实践的方法。
这4个核心主张可帮助读者领会ADMEMS方法之精髓。
ADMEMS 方法体系: 3个阶段， 1个贯穿环节
作为方法体系，ADMEMS方法通过3个阶段和1个贯穿环节，来覆盖“需求进，架构出”的架构设计完整工作内容。
图1-5说明了“3个阶段”在整个方法体系中的位置。具体而言:
预备架构 (Pre-architecture) 阶段(简称PA阶段)。
最大误区: 架构师是技术人员不必懂需求。
实践要点:摒弃“需求列表”方式，建立二维需求观。
思维工具: ADMEMS矩阵等。
概念架构 (Conceptual Architecture)阶段(简称CA阶段)。
最大误区:概念架构=理想设计。
实践要点:重大需求塑造概念架构。
思维工具:鲁棒图、目标-场景决策表等。
细化架构(Refined Architecture)阶段(简称RA阶段)。
最大误区:架构=模块+接口。
实践要点:贴近实践的5视图法。
思维工具:包图、包-接口图、灰盒包图、序列图、目标-场景决策表等。
ADMEMS方法体系包含3个阶段
值得强调的是，上述3个阶段之间的先后顺序有极大的实际意义，否则就不能称其为“阶段”了:
试想，在Pre-architecture阶段对需求理解不全面( 例如遗漏了需求)、不深入(例如没有发现“高性能"和“可扩展”是两个存在矛盾的质量属性),后续设计怎会合理?
试想，Conceptual Architecture 阶段的概念架构设计成果没有反映系统的特点就“冲”去做Refined Architecture设计，是不是必然造成更多的设计返工?
“1个贯穿环节”，指的是对非功能目标的考虑。
概念架构的故事
架构新手和有经验架构师的区别之-一，在于是否懂得，并能有效地进行概念架构设计。作为架构新手，尤其害怕碰上自己没做过的系统;系统较大时，一旦祭出“架构=模块+接口”的法宝却不太奏效，架构新手就往往乱了阵脚。相反，有经验的架构师不会-上来就关注如何定义“接口”，他们在大型系统架构设计的早期比较注重识别重大需求、特色需求、高风险需求，据此来设计概念架构。
另外，概念架构还是投标及售前工作的有力武器。金牌售前和普通售前的一一个重要区别是,能否清晰地讲解概念架构，并借此说明“客户关心的价值如何实现、担心的问题如何解决”。
探究:“方案”与“架构”的关系
究其原因，这是因为概念架构难以支持并行开发。要支持开发组相对独立地进行工作，须要提供指导和限制作用更明确的“规约”一级的设计。
具体而言，细化架构和概念架构之间存在如下典型差异:
接口。在细化架构中，接口占据非常核心的地位，而概念架构并不关心明确的接口定义(只有抽象的组件和抽象的交互机制)。
子系统。细化架构重视通过子系统和模块来分割整个系统，并且子系统往往有明确的接口;而概念架构中只有抽象的组件，这些组件没有接口，只有职责一般是处理组件、数据组件或连接组件中的-种。当然，概念架构中也有“大组件分解成小组件”的设计决策，但并非子系统的含义。
交互机制。细化架构中的交互机制应是“实在”的，如基于接口编程、消息机制或远程方法调用等;而概念架构中的交互机制是“概念化”的，例如“A层使用B层的服务”。
就是典型的例子，这里的“使用”到了细化架构中可能基于接口编程、消息机制或远程方法调用等其中的一种。
当然，概念架构和细化架构都满足软件架构的定义一-无论是“架构= 组件+交互”,还是“架构=重要决策集”。
方案的制定，为什么需要项目负责人、需求人员、架构师等共同参与呢(如图11-1所示) ?
因为方案涉及的工作内容不仅仅是架构，还涉及项目管理和需求工作。“方案” 和“架构”的联
系与区别如下:
方案包含- -定的架构内容。
方案涉及的架构基本在概念架构一级。
架构设计的工作还远未完成。
方案制定需要项目负责人、需求人员、架构师等角色的共同参与
所以，架构师应记住:
方案=“项目+需求+架构”的总览
方案≠架构的全部
逻辑架构
划分子系统、定义接.....这些典型工作都属于逻辑架构设计的范畴。
本章阐释ADMEMS 5视图方法中逻辑架构视图的设计:
先从划分子系统的3种必用手段讲起;
随后，纠正“我的接口我做主”这种错误认识，代之以“协作决定接口”的正确理解;
而且，本章将解析逻辑架构设计的整体思维套路，解决一线架构师郁闷已久的“多视图方法只讲做什么、不讲怎么做”的问题:
最后，总结逻辑架构设计的10条经验要点。
相对于逻辑架构设计而言，物理架构视图的设计是不是就乏善可陈呢?不。一线架构师最缺的是物理架构的设计思维。
从设计结果层面，决策无非围绕物理节点、网络、软件单元、数据单元等内容展开。
但是，思维当中经历了哪些思考、判断和权衡呢?
从最终目标层面，决策要兼顾多方涉众的不同利益，可从“攻”与“守”两个方面理解:
高性能(攻)。
持续可用性(攻)。
可伸缩性(攻)。
经济性(守)。
技术可行性(守)。
易维护性(守)。
从思维要点层面，“开销”和“争用”是核心。架构师正是通过“降低开销”、“避免争用”来实现高性能、高可伸缩性等最终目标的:
如何降低物理节点“内”的计算开销?
如何降低物理节点“间”的通信开销?
如何避免物理节点“内”CPU、内存、硬盘等资源的争用?
如何避免物理节点“间”网络的带宽资源冲突?
至此，我们了解了物理架构设计的理性思维框架，如图14-2所示。
物理架构设计的理性思维框架
由于篇幅过长，小编在这里就不一一为大伙介绍了，有需要【一线架构师实践指南】技术文档的小伙伴，只需要关注+转发+评论，获取++++++我v x ①⑦⑧③⑤零⑥⑧⑤⑦⑥ 就可以获取了
