这本书教 FDE 算清每个架构选择的代价

“软件架构里没有容易的决定。”出版方的介绍以这样一句近乎坦白的话开篇。这本书的书名也难得诚实：Software Architecture: The Hard Parts，副标题是“分布式架构的现代权衡分析”，作者是 Neal Ford、Mark Richards、Pramod Sadalage 和 Zhamak Dehghani。

对前线部署工程师（FDE）来说，这句话就是普通的一个工作日。到了客户现场，面对的是一套遗留系统、一个共享数据库，还有几个都不希望别人动自己那一块的团队。接下来，你要在几周之内把公司的产品接到这一切上。

这本书不教你哪种技术最好。它教的东西更难：掂量每个方案得到什么、付出什么，再用清楚的理由向客户解释。

这本书从何而来？

O’Reilly 于 2021 年 11 月 5 日推出纸质版，全书约 450 页，ISBN 978-1-4920-8689-5。它并非一气呵成。据 Neal Ford 的培训页面介绍，几位作者先讲了好几年工作坊和培训课，内容和讲法都逐步打磨，最后才成书。

因为脱胎于课堂，这本书读起来像一门有人物的课程。它不罗列模式，而是跟着一支名为 Sysops Squad 的虚构团队，走过一连串决策：服务做大还是做小，服务之间的契约应该是什么样，分布式事务怎么处理，运营特性会受到哪些影响。

本书的承诺很直接：帮你在分布式架构的权衡取舍上提高批判性思考能力。Ford 还强调，权衡分析不只是专家的事，每位架构师都能从中受益。

向客户当面解释这类决定的，往往正是 FDE，所以这几乎是每周都要用到的能力。

第一点：契约严格还是宽松，是决策而不是习惯

Ford 的课程大纲里专门有一节叫“Strict Versus Loose Contracts”（严格契约与宽松契约）。对 FDE 而言，这大概是明天就能用上的内容，因为几乎每次部署都从读取客户系统的数据开始。

假设客户的订单 API 返回 40 个字段，而你的 Agent 只需要其中 3 个：订单 ID、状态和最后更新时间。

如果 40 个字段全部严格校验，客户那边某个团队只要改了一个你根本不用的字段名，你的数据管道就会在半夜崩掉。如果只读需要的 3 个字段、其余一概忽略，这类变更就影响不到你。

但宽松契约也有代价。错误可能悄无声息地漏过去，比如状态字段的取值毫无预警地变了。严格契约能尽早发现错误，却把双方绑得很紧；宽松契约能容忍变化，代价是你得自己监控数据。

在客户现场，第一件事是去问负责这个 API 的团队：schema 多久改一次？坏数据的后果有多严重？这两个答案决定你往哪边倾斜。

小练习：从正在用的某个 API 里取一份真实响应，数一数代码实际读取了几个字段。为每个字段写一行：如果这个字段改了名或取值变了，你希望系统立即报错，还是继续运行并发出告警？

第二点：多小才算够小？

大纲里还有一节讲“Service Granularity”（服务粒度），即系统各部分应该切多大。客户手里有一个单体应用、想做现代化改造时，常见的条件反射是立刻提议上微服务。这本书逼你先停一停。

举个假设的例子：下单流程拆成订单、支付、库存三个独立服务。在单体里，这三步整齐地放在一个数据库事务中。拆分之后，如果支付成功而扣库存失败，就再也没有一次回滚能覆盖全部三步了。

这就是分布式事务问题，也是书中讨论的主题之一。你获得了独立性，代价是网络调用、协调开销、某一步失败时的补偿逻辑，以及更难的调试。

在给客户画拆分图之前，先问清楚：哪些部分确实以不同的速度变化，哪些必须在同一时刻保持一致？如果三个部分总是一起变、也必须一起正确，拆开只会徒增工作量。

小练习：挑客户的一条业务流程，列出每一步，标出必须同时正确的步骤。总是一起变动的分组留在同一个服务里，只有分组之间的边界才值得考虑作为拆分点。

第三点：数据最难拆

大纲中有一节叫“Pulling Apart Operational Data”（拆分运营数据）。拆代码相对容易；而一个计费、物流、报表都在读写的数据库，拆起来要难得多，集成项目通常也在这里卡得最久。

假设你需要让 Agent 读取订单状态。直接读共享数据库很快，但会把你绑在一个没人承诺保持稳定的内部 schema 上。请客户开放一个 API 要慢几周，但能换来清晰的边界。两种做法都不算错，这本书教你把各自的代价说清楚。

小练习：为 Agent 读取的每张表记下归哪个团队所有、还有谁在写。写入方最多的那张表，就是你最该先申请 API、而不是直接读取的地方。

谁适合读，按什么顺序读？

这本书适合有几年经验的工程师：熟悉服务、API 和数据库，并开始自己做架构决策。如果刚毕业，还没亲自为某个决定买过单，450 页讲权衡取舍的内容会显得相当抽象。

高效的读法是从头跟着 Sysops Squad 的故事线走，看清各个决策之间如何关联。然后回头细读拆分运营数据和契约这两部分，这是 FDE 最常碰到的两个话题。服务粒度和分布式事务，可以留到客户问起现代化改造时再看。

从职业发展看，这种能力是别人看得见的。职位描述里写着“对接客户系统”时，就应理解为每周都要做这类权衡。

简历上不要只写“对接过 ERP 系统”。要写明你选择通过 API 读取而不是直接读数据库，并接受了两周的延期，换来一个稳定的边界。

练习系统设计时，养成把方案的代价说出来的习惯，而不只是报出技术名词。这本书不会给你答案，但能帮你在客户开口之前，先向自己提出这些问题。