对于《一线架构师实践指南》中 第三编——Refined Architecture阶段 的个人见解

日期：2020.04.09

博客期：171

星期四

 

　　《一线架构师实践指南》中 第三编——Refined Architecture阶段 分布在第11章开始。

　　文章开篇以一个 “《方案书》确认之后” 的小故事，鲜明地点出了 “总体设计” 是方案更详细的设计而且必须有指导和限制程序员的能力才行两部分要素。在这“细化架构部分”，文章的开头部分就是直接讲述了 “方案” 与 “架构” 的关系，讲到了它们的差异性和 “公式”：　

方案 = “ 项目 + 需求 + 架构 ” 的总览
方案 ≠ 架构的全部

　　这是作者在 “方案” 和 “架构” 之间的思考，我觉得这两个公式合在一起理解呢，就像方案是 大局总览 ，而 架构 相当于是 项目中的编码的总体设计结构。

　　之后作者提笔写实的例子并自己总结：不同涉众看待软件架构的视角是不同的。其实非架构师是这么认为的——架构应该怎么为 “我” 服务。所有非架构师都是想架构能怎样的帮助到自己的工作，所以视角会不同。而 “多视图”的方法就是针对不同的人员绘制的，我们需要将这种方法融汇到一线架构师的各项具体的工作中。

　　然后到第12章的时候，我们介绍了 Refined Architecture 它究竟是个啥。它也本身给了对于 5 视图的关系以及它们之间的内部构成和区分：

 

 　　之后一章—— 逻辑架构 的部分，主要是讲划分子系统，应该是三步走原则——分层、分区、机制的提取（分别对应横向划分、纵向划分和模块协作，也可以对应职能划分、通用单元分离）。按我的原则来说，我们是在 “概念架构” 完成的基础之上进行的 “逻辑架构” ，“概念架构”为我们划分领域、划分团队任务、划分需求，而 “逻辑架构” 为我们划分每一个领域、每一个团队任务、每一个被划分的需求的子系统。分层完成了层次的细化，分区方便了程序员迭代开发，机制的提取是各个模块通过接口相互协作。注：机制是指基于接口（抽象类）的协作，不可以是具体类的。而且事实证明，“分”是手段，“合”是目的，最终的机制提取才是真正的有时效的逻辑架构活动。从某种意义上来讲，接口的定义被具体协作过程所约束。当然，我们需要先依此完成包图的设计，最后我们可以使用时序图来描述各个模块之间的协作情况。

　　那么，第14章讲到 物理架构、运行架构、开发架构。它们解决的刚需问题分别是 “增加硬件 = 增加计算能力 ≠ 软件的实际服务能力增强”、“并行、并发处理，基于SDK等等做定制开发”、“开发人员没能按照架构开发项目”。对于它们的设计内容，我给附上原图：

 

　　物理架构是面向硬件的高效率使用合维护的，运行架构的关键是要通过绘制控制流图来展现物理架构完成的几个物理点之间的运行状态信息，开发的过程比较注重 “可重用性”这一质量属性。

　　最后一部分是 数据架构 。文中直接就写道“数据分布是难点”，说数据具有 Schema 独立性，数据根据系统划分成两两独立的表格；说数据要集中存储、但要访问分布；说数据要分区相应数据表，不同用户的权限，得到的数据表也不同；说数据满足复制特性合子集特性——结点实时更新或快照更新；说数据要可以打乱重新组成新的数据表。对应下面的策略分析图：