整洁架构

《架构整洁之道》终于到了《整洁架构》一章。

整洁架构书中画了个同心圆，外层依赖内层，内层不能依赖外层。

整洁架构

这个同心圆依赖关系规则的出发点是认为外部的是多变的、可替换的、可移植的、开发者不希望花太大精力投入的。

最外层是设备、数据库、外部接口、用户界面、web这类框架与驱动程序。如之前所说，系统设计的时候尽可能延后决策，这就要求系统设计的时候对设备等进行抽象，至少要做一个隔离层。这启发我们不要依赖于具体的底层实现如交互方式，以便将来做平台移植的时候减少投入人力。近期我对我们的代码架构做了一次评估调查，发现底层通信方式的变更导致了某个组件整个重写，这就是不合理的依赖带来的代价。我也一直强调，不要把外部接口引到组件内部，甚至想把这一条作为代码合入的自动化检查标准，也是考虑到外部变更会导致内部频繁修改。

所谓隔离层，书中也称作网关、展示器、控制器。旁边也标注了叫做接口适配器。接口适配器很好理解，总有一个层要隔离外部变化，并把外部消息转为内部能够处理的数据。那么展示器是什么？我想应该是图像显示类程序中对图像数据的中间处理，与之相对的是像素点直接处理函数。控制器是什么？书中没有细说，似乎是参数配置模块，负责系统对配置参数的响应与转发。

用例层，书中也称作应用级业务逻辑。这部分应该是根据参数配置，生成场景，所以我更希望叫做场景层。参数配置好之后，业务实体按照场景执行。

系统的核心是业务实体。业务实体也应该是分层的，分为流程层与实现层。流程层定义了系统业务架构，实现层实现这些流程的细节。

既然有分层，就必然存在层次边界问题，书中没有细说，我谈一下我的理解。从性能和复杂度平衡角度，我认为所有的复杂度应该尽量向外层靠拢，接口适配层能完成的工作就不要到场景层和领域层。上面四层不是绝对的，至少我觉得还必须有基础设施层，用于提供整体公用的宏定义、小工具实现等功能。

整洁架构和组件，是从不同的角度在定义系统。整洁架构可以是组件内的，也可以是组件外的，是一种架构设计方法。组件按照康威定律，必然与团队是对应的，组件边界即团队工作边界。下面谈一下组件边界。

组件边界在第13章已经讲过组件聚合三原则，这里主要讲组件边界是怎样形成的。我在书里写了这么一行字“变化方向->抽象->形成边界”，边界不是一次形成的，而是在演进的过程中新的变化方向引入了新的抽象，抽象后形成了新的边界。现存的边界也不是一成不变的，随着需求的增加，团队之间进行着边界的突围与撕裂，被撕裂的组件工作量越来越大，因为一个边界的让步将引发后续一大批需求的改动，这个时候我感到非常困惑，架构师是否应该参与到这类争执不下的边界冲突中来作为一个中立者给出从系统角度的合理结论，似乎属于架构师的责任，但这些微观的小边界又往往是很难说清的。近期我对架构的评估调查，也着重调查了组件边界争执的问题，争执往往是因为组件间存在相同的概念，而相关概念的各自责任又没有由架构师确定下来，相关问题的解决之道还需要深入摸索。