HackerNews中文版

我曾经认为，在服务之间定义清晰的接口和契约，就足以维持模块化。我共享一个数据库，因为它看起来是最省事的做法。我错了。共享数据库或任何跨越到外部组件边界的资源，都会创建一个“焊接”接头，它无视任何接口定义。这会引发一连串的故障，随时可能发生。<p>许多工程师希望避免严格定义数据所有权带来的摩擦。他们寻求一个礼貌、中立的区域来避免冲突。我认为这种方法在智力上是不诚实的。通过避免执行真正模块化所需的冲突，你构建的系统注定会在模式发生变化的那一刻崩溃。<p>我不得不为此付出惨痛的代价。我现在对每个组件的数据层都强制执行严格的分离。这在前期更难，但它是构建能够扩展而不会因自身重量而崩溃的系统的唯一方法。如果你正在共享数据库，或者以任何方式让你的域数据跨越到外部模块的边界，那么你并没有构建一个模块化系统。你只是在推迟不可避免的崩溃。

查看原文

I used to believe that defining clean interfaces and contracts between services was enough to maintain modularity. I shared a database because it seemed like the path of least resistance. I was wrong. Sharing a database or any resource that crosses the boundary to a foreign component creates a "welded" joint that defies any interface definition. It creates a failure cascade waiting to happen.<p>Many engineers want to avoid the friction that comes with strictly defined data ownership. They seek a polite, neutral zone to avoid confrontation. I believe this approach is intellectually dishonest. By avoiding the confrontation required to enforce true modularity, you build systems that are destined to fail the moment a schema changes.<p>I had to learn this the hard way. I now enforce strict separation at the data layer for every component. It is harder upfront, but it's the only way to build systems that scale without collapsing under their own weight. If you are sharing databases or making your domain data cross the boundaries to foreign modules in any way, you are not building a modular system. You are just postponing the inevitable breakdown.

共享数据库不是模块化的，它们只是一个弱点。