架构方法实践 - 客户端CAD工具范例 (三 详细架构部分)

接上回。在架构活动中，从收集需求→多维需求ADMEMS分析→重大需求获得概念架构→鲁棒图分析

→分层分区模块，我们很自然的就来到了细化架构的阶段。

在细化架构中，主要要解决架构具体化的问题，目标是形成开发的指导性基础，大项目要求能指导多个团队进行并行开发。这个步骤具体是通过一系列不同角度的视图，去验证，去叙述，去设计每个子系统视图中模块和模块的关系。粒度的粗细应该介于高层架构（确定子模块和子模块之间的关系）和实现，模块设计之间。在这个阶段中也要关注非业务需求，比如性能。通过这个阶段的设计，架构设计就基本落地了。

细化架构设计的多视图：包括逻辑视图/物理视图/运行时视图/开发视图/数据视图，各自从不同的方面反映架构。

1）逻辑视图：包含系统职责的切分，逻辑层，接口，模块，子系统的切分及其交互研究，个人认为在Coding前的必经之路。

2）运行架构：包含系统一些关键核心功能的运行控制流设计，进程/线程任务调度， 锁的设计。个人认为这里是对系统时序复杂的地方的解析。

3）物理架构：包含系统物理层的设计，即配置设计，节点和计算资源的分配。

4）数据架构：包含系统数据存储的设计，指数据库配置的策略，不是指数据库/表设计。

5）开发架构：包含源码的组织和配置设计。个人认为对于成熟的开发团队，这一项的作用不是那么重要。

2），3）, 4)在互联网服务中使用比较多，对于本文的CAD工具例子，重点讲一讲逻辑架构，顺带讲一讲数据架构。

架构方法实践 - 客户端CAD工具范例 (二 概念架构部分) 文中末尾从鲁棒图推演了如何将分层，分区带入逻辑架构，另外再补充一点，将公共的部分分离，形成机制。机制是什么呢？Grady Booch 在他的著作中指出:机制才是设计的灵魂所在......否则我们就将不得不面对一群无法相互协作的对象,它们相互推搡着做自己的事情而毫不关心其他对象。基于接口(和抽象类)的协作是机制,基于具体类的协作则算不上机制。机制是隐式的可抽取的重复代码。

我们可以将前文中的简单分层，分区图细化为详细的逻辑设计图，辅以机制萃取：



逻辑上工具分为5层，分为文件读写/对象实体/算法/控制器/GUI 5层，文件读写包括DXF的读取，Template circuit数据的保存。实体层代表内存中存储的对象，需要支持2D显示，编辑，比如DXF的常用对象，也包括Template中的对象，比如图层，模板参数等。算法层包括Template处理算法，构建点线弧图元为多边形图元的算法以及Circuit Design中的物理连接等算法。控制器层包括Template数据操作，编辑，选择等工具。GUI层则是各个功能点的展示。另外，也抽象出几个机制：几何绘制，几何实体编辑，构建多边形，回滚等等，这些都是抽象对象间的交互，可以抽取出来。

到这里，逻辑的细化架构可以说落地了，下面还需要：

1）对每个子模块验证，通过质疑提出问题，并验证。通过数次修复逻辑错误和验证的循环寻找重大的缺陷。

2）对时序上可能复杂的地方重点分析，如果需要，进行运行时视图的分析。

3）拆分模块，估算工作量，开发。

由于这个客户端CAD工具没有需要详细分析 物理/运行/开发/数据 视图的细化架构，这里略去。

最后，个人认为数据分布方案也是架构的难点，数据分布方案可以分为独立schema（每个app使用独立的数据库）, 分区（根据用户地点或字段拆分数据库），集中（所有app共用数据库）复制，子集，重组数据等几种配置方法，在可靠性，可伸缩性，可管理性，数据一致性，通信开销上各有胜负，要根据情境和需求进行选择，具体可以找寻资料深入研究。个人水平有限，希望和大家共同学习。