一线架构师实践指南总结（三）—— Conceptual Architecture

什么是概念架构

概念性架构界定系统的高层组件，以及它们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约及架构图，但不涉及接口细节。

实际意义

1.不同系统的架构，为什么不同？
需求不同，所以架构不同。这里需求包括了功能、质量、约束等方面。

2.架构设计中，应何时确立架构大方向的不同？
进行概念架构设计时应确立架构大方向。架构设计贵在有针对性，概念架构针对重大需求、特色需求、高风险需求的要求，给出高层次的解决方案——这就是概念架构的最重要意义。

实践要领

重大需求塑造概念架构
ADMEMS方法Conceptual Arch阶段核心理念：重大需求塑造概念架构，这里重大需求应涵盖功能需求、质量及约束3类需求的关键部分。

概念架构阶段的3个步骤
1.初步设计。基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计。
2.高层分割。对系统这个黑盒子进行高层切分，例如切分复杂系统为多个二级系统，或者直接切分系统为具体子系统。
3.考虑非功能需求

初步设计

初步设计对复杂系统的意义
1.架构师只有在设计复杂系统（或涉及不熟悉的领域，感受“挺复杂”）时才需要初步设计。
2.初步设计的目标：发现职责。无须展开架构设计细节。
后续的架构实际工作必然以初步设计为基础。

鲁棒图简介
鲁棒图包括3种元素，分别是边界对象、控制对象、实体对象：
边界对象对模拟外部环境和未来系统之间的交互进行建模。边界对象负责接收外部输入，处理内部内容的解释，并表达或传递响应的结果。
控制对象对行为进行封装，描述用例中事件流的控制行为。
实体对象对信息进行描述。

例如

基于鲁棒图进行初步设计的10条经验
1.遵守建模规则

2.简化建模语法

3.遵循3种元素的发现思路

4.增量建模
先识别最“明显”的职责->开始考虑职责间的关系，并发现新职责->继续考虑职责间的关系，并发现新职责->直到模型比较完善

5.实体对象≠持久化对象

6.只对关键功能（用例）画鲁棒图

7.每个鲁棒图有2～5个控制对象

8.勿关注细节

9.勿过分关注UI，除非辅助或验证UI设计

10.鲁棒图≠用例规约的可视化

高层分割

高层分割的两种实践套路：
“高层分割”的两种实践讨论：切系统为系统；切系统为子系统

切系统为系统
具体指：
1）系统比较复杂，需要进行两级高层切分。
2）首先，把系统切成更小一级的系统，每个更小一级的系统都可以有单独的需求、设计、实现…
3）之后，针对每个“更小一级的系统”，进行“切系统为子系统”…
例子：

切系统为子系统
最常见就是分层。
例子：

分层式概念架构

分层“3+1种”流派：
Layer：逻辑层
Tier：物理层
按通用性分层
技术堆叠

Layer：逻辑层
逻辑层重视职责的划分，职责之间常常是上层使用下层的关系——但是不关心上层和下层是否能分布在不同的机器。

Tier：物理层
物理层指能分布在不同机器上的软件单元，不同物理层之间必须有跨机器访问的能力——可以通过远程条用、或通信协议等方式。

按通用性分层
指：将通用性不同的部分划归不同的层，以此作为系统的总体切分方式。

一般而言，通用程度越大，所处的层次越靠下。例如

嵌入式系统分层架构通用性越强的层，位于中间，硬件相关部分，以及应用特定部分分别位于下层和上层。例如

技术堆叠
技术堆叠不是独立的架构模式，而是基于分层架构（或其他架构模式）提供的进一步说明。
例如

考虑非功能需求

考虑非功能目标要趁早
概念架构不等于理想化架构。ADMEMS强调：
1）重大需求塑造概念架构。
2）概念架构是一个“架构设计阶段”，必须在细化架构设计阶段之前，针对重大需求、特色需求、高风险需求，形成稳定的高层架构设计成果。
3）如果只考虑“功能需求”来设计概念架构，将导致概念架构沦为“理想化架构”，这个脆弱的架构不就就会面临“大改”的压力，甚至导致投板等工作失败。