更智能的软件架构打造更聪明的团队

Source: Dev.to

1. 过程式开发：通往孤立的舒适之路

过程式工作很简单：

输入 → 逻辑 → 输出。

把逻辑放进一个服务。起个名字比如 OrderService 或 FooManager。
写测试。让它们全部通过。完成。

在这个世界里：

• 工作可以单独完成。
• 讨论是可选的。
• 共享理解并非必要。
• 功能是一张工单，而不是一个想法。
• 架构只是文件夹结构。
• 进度用打勾来衡量。

团队并不围绕 意义 聚集；根本没有意义——只有任务。过程式代码库是一片平坦的景观：所有事物看起来同等重要也同等不重要，没有重心或概念层级。

对团队的影响

• 每个人都单独工作。
• 每个人都构建自己的小世界。
• 所有事物都同样脱节。
• 所有权被碎片化，因为系统本身就是碎片化的。

过程式团队会变成一群可互换的工人，交付可互换的逻辑。这不是团队的错——是架构的错。这种做法只能在一个维度上扩展：人力。

2. 丰富领域模型：协作的天然磁铁

丰富的领域模型拥有结构、意义，且体现了产品的本质。当系统映射真实世界——包含概念、不变量、边界和协作时，你再也不能孤立工作。你必须交流、理解并对齐，因为每一个新能力都会插入已有的东西。

典型的问题会转向产品而非纯技术：

• 这个概念如何与其他概念交互？
• 谁拥有这个行为？
• 已经有模型捕获了这个关注点吗？
• 这个职责应该在这里，还是在别处？

这些对话会吸引设计师、业务专家、分析师和产品负责人。

在建模团队中

• 领域模型成为共享的心智地图。
• 每个人指向相同的概念对象。
• 讨论变得更容易、更快、更丰富。
• 整个产品被更多人所理解。
• 所有权变成共享责任，而不是工单所有权。

领域模型 迫使 团队成为真正的团队——它是大家围坐的篝火。

3. 反直觉的现实：丰富模型更快

有一种误解认为过程式开发更快，因为“你可以直接开始编码”。事实是，两种方法的起点速度相同，只有一种会随时间加速。

使用丰富模型时

• 结构指引新特性。
• 复杂行为成为已有行为的组合。
• 规则、约束和不变量已经内嵌。
• 许多决策已经由模型做出。
• 你写的代码更少，错误更少。

过程式代码不会产生复合效应；领域建模会。过程式代码库永远不会加速——它们只会累积重量。

在过程式系统中

• 每个新特性都是一次小规模的重新发明。
• 每个服务都是一个新的逻辑碎片。
• 每次改动都会触及多个位置。
• 每个新需求都会暴露之前的捷径。

没有杠杆——只有劳动。

4. 那么为什么过程式占主导？（因为它的成本是看不见的）

如果领域建模能带来更好的团队、更快的开发和更高的质量，为什么过程式开发仍然主导行业？因为组织优化的是 可替换性，而不是 有效性。

过程式代码的特点是：

• 易于招聘
• 易于外包
• 易于估算（“只要建个服务”）
• 易于在内部替换人员
• 易于向管理层解释
• 易于在电子表格中正当化

但它 并不 便宜；它只是 隐形昂贵。长期成本——开发缓慢、缺陷、重写、微服务膨胀、协作开销、认知负荷——悄然累积。软件不会爆炸，它会悄然衰退。

我在这里写了一篇深度分析：
Why IT Is an Expensive Mess — And Why Nobody Inside IT Notices

5. 如果你想要可替换性，就别把工作简化——让开发者更聪明

当前的企业逻辑是这样：

“我们想要可互换的开发者，所以应该把工作简化到最低公分母。”

这直接导致：

• 过程式代码
• 服务大杂烩
• 无尽的微服务
• 工单取代设计
• “只要再加个服务”思维
• 只能通过增加人手来扩展的脆弱系统

我们需要相反的做法。如果你想让开发者具备适应性、可替换性和高效性：

• 给他们技能，而不是被简化的任务。
• 给他们模型去理解，而不是一堆服务文件夹。
• 给他们清晰，而不是碎片化。

强大的模型创造 灵活而不混乱。过程式的混乱则是 伪装成灵活的混沌。

6. 团队行为遵循技术结构

核心论点： 你的架构决定团队动态；团队动态决定产品。

你无法在薄弱的结构上建立强大的团队，也无法在过程式碎片上实现产品所有权。真正的团队协作需要值得围绕的东西：捕获产品意义的模型。

7. 结束语

团队并不是通过站会、回顾或桌游就能成为团队。团队之所以成为团队，是因为他们必须一起思考，而共同思考只有在有可思考的对象时才会发生：

• 共享的语言
• 共享的概念
• 共享的结构
• 共享的意义
• 共享的责任

过程式开发消除了共享思考的需求；领域建模则创造了它。一条路通向孤立的工作者和昂贵的系统；另一条路通向真正的团队和真正的产品。选择那条能够同时构建产品 和团队 的道路吧。