代码库设计

设计深模块：小接口背后藏大量行为，接口位置干净，可通过该接口测试。凡是在设计或重构代码的地方，都用这套语言和这些原则。目标是给调用方杠杆、给维护者局部性、给所有人可测性。

术语表

严格使用这些术语——不要替换成"组件"、"服务"、"API"或"边界"。统一的语言就是全部意义所在。

模块（module） —— 任何有接口和实现的东西。刻意不分规模：一个函数、一个类、一个包，或一条横跨多层的切片。避免：单元、组件、服务。

接口（interface） —— 调用方要正确使用该模块所必须知道的一切：类型签名，也包括不变量、顺序约束、错误模式、必需的配置，以及性能特征；同时也是模块与外界相接、两侧可独立变化的那道边界（Michael Feathers 的 seam 就是它，不必另起一名）。接口放哪里、对外暴露多宽，本身就是一项独立的设计决策，与接口背后放什么分开。避免：API、签名（太窄——只指类型层面的那一面）、接缝/缝/seam（就是接口）、边界（与 DDD 的限界上下文撞了）。

实现（implementation） —— 模块里面的东西，它的代码体。与适配器区分开：一个东西可以是小适配器 + 大实现（一个 Postgres 仓库），也可以是大适配器 + 小实现（一个内存 fake）。接口位置是话题时用"适配器"，否则用"实现"。

深度（depth） —— 接口处的杠杆：调用方（或测试）每学一个单位的接口，能驱动多少行为。一个模块是深的，当大量行为藏在一个小接口背后；是浅的，当接口几乎和实现一样复杂。

适配器（adapter） —— 在接口处满足某个接口的具体物。描述的是角色（填哪个坑），不是内容（里面是什么）。

杠杆（leverage） —— 调用方从深度里得到的东西：每学一个单位的接口，能拿到更多能力。一份实现，在 N 个调用点和 M 个测试里都还回来了。