模块化单体：大多数初创公司应从此开始的架构

Source: Dev.to

“只想直接使用微服务”的问题

• 微服务解决的是 组织规模，而不是早期产品的混乱。
• 初创公司通常面临：
  • 资源有限
  • 需求快速变化
  • 小团队

微服务会带来：

• 复杂的部署流水线
• 增加的运维开销
• 分布式调试的挑战

你用一个难题（代码结构）换来了五个新难题。在这个阶段，这种权衡很少合理。

什么是模块化单体

模块化单体 是一个可部署的单一应用程序，但内部边界非常明确。

关键特性

• 清晰的模块边界（例如 /users、/billing、/analytics）
• 每个模块封装自己的领域逻辑和数据访问
• 不仅仅是文件夹结构；边界通过代码和架构强制执行

为什么它在早期如此有效

• 运行成本低 – 部署一次，基础设施费用保持可预测。
• 变更快速 – 需求每天都在演进，单一代码库更易修改。
• 安全更容易 – 只有一个应用，暴露的表面更少。
• 团队清晰 – 即使只有两名开发者，也不存在 “谁把生产环境弄坏了？” 的谜团。

最关键的部分：清晰的边界

如果忽视边界，模块化单体就会失败。

我坚持的规则

1. 模块必须拥有自己的数据，绝不能访问其他模块的表。
2. 模块之间的通信必须通过明确定义的接口或服务进行。
3. 禁止循环依赖；每个模块都应能够独立测试。

如果不遵守这些纪律，单体很快会退化成一团乱麻的代码库。

扩展的故事（它的闪光点）

当真正需要扩展时：

• 现有的模块化结构使得抽取服务变得直截了当。
• 可以 逐步 将高流量模块迁移到独立的微服务。
• 不需要完整重写；架构会 演进，而不是重置。

为什么我向早期创始人推荐它

• 为速度、成本和简洁性进行优化。
• 让你在关注产品‑市场匹配时，避免工程复杂性。
• 你并不是在抵制微服务，而是 推迟 采用它们，直到真的需要。

这种纪律是务实的工程实践，而不是对变化的恐惧。

最后思考

微服务并不是严肃度的徽章。
最昂贵的架构往往是你在还未真正理解问题之前就搭建的。

从模块化单体开始。 让真实的规模自然带来复杂性。