架构设计的新思路，《架构之道》读书笔记

《righting software》是 Pearson 出版社 2020 年出版的一本书，作者是 Juval Löwy，今年国内也引进了这本书，中文名是《架构之道》。

中秋期间读完了这本书里我比较关心的部分，本文将其中的一些核心观点进行摘录。

作者首先总结自己几十年的经验(先表达一下羡慕)，提出了靠谱软件的设计方法，称为 The Method(中文译成了元方法)：

The Method = System Design + Project Design

这本书也就被分成了这两部分，System Design 和 Project Design。

先说说 Project Design，这个其实就是项目规划，这部分大多数公司的项目管理培训中都有科普，就是通过对项目的工作任务进行拆分，绘制出网络图，找到迭代的关键路径，并为不同阶段分配不同的开发资源。看一下这张图你基本就懂了：

尽管作者把项目管理也放在了架构师的职责内，不过这些事情一般都是项目经理来干的(很多项目进了中后期，日常迭代其实都不需要做什么分析了，都是堆嘛)，作者也没有提出让人眼前一亮的观点，本文会先忽略应该没什么人感兴趣的这个部分，大多公司的项目管理方式也比较粗放，循规蹈矩的做基于网络排期的公司很少很少。

System Design 对我们来说比较重要，一线软件开发和架构师每天的日常工作都会或多或少涉及一点设计。关于 System Design 的部分是这本书的上半部分，中文版总共 102 页，所以读起来也是比较快的。

微服务模式已经是后端架构模式的大前提，我们最耳熟能详的对微服务建模的观点一般是“基于功能”或“基于领域”拆分出来的微服务。实际的情况是，大多数一线工程师还在吵吵用不用 DDD，因为那几本 DDD 的书实在是写的太难读了。之后有机会我也写写 DDD 的科普文，应该没那么难的。

这本书就很神奇了，作者既不赞同基于功能进行拆分，也不赞同基于领域拆分。

为什么不赞同基于功能拆分？

这里给出了五个理由：

服务很难重用

比如拆分了三个服务 A、B、C，看起来是三个独立的服务，但在执行 B 的时候，其实需要 client 先去访问 A 拿到 B 所需要的参数。访问 C 需要先从 B 中拿一些参数。

这样 A、B、C 都不是独立的服务，他们是一组服务，你没法单独复用任何一个。

数量过度或规模过度

这个我们在大公司内见的比较多了，比如国内的几家规模比较大的公司，服务数量都超过 10 w 了，喜欢规模的人看到这些数字反而还会比较高兴。有些服务总共也就几千行代码，实现功能单一的简单逻辑。

还有那些没拆好的，单服务几十万行~100w 行代码的服务，本人也是实际见过的。

客户端臃肿耦合

服务数量爆炸会导致集成的难度变高，客户端的会随着服务数量的膨胀同步变复杂。作者这里没提到 BFF，不过 BFF 其实也没有降低集成复杂度，只是把这部分从 client 移到了 BFF 里。

下面这张图是一个基于功能拆分的系统，在迭代一段时间后，客户端侧的圈复杂度的综合统计：

模块的复杂度分布极不均衡，组件极多，这里的 Resources 模块变得很大，就是因为后端服务数量太多造成的。

服务数量多导致的逻辑冗余

上面把很多服务都直接暴露给了客户端，导致每个服务都需要集成身份验证、授权、可伸缩、事务传播、等等等等。

这条其实有个 BFF 就还好了。

服务臃肿耦合

如果不想让 client 访