共享数据库并不是模块化的,它们只是一种弱点。

1作者: davidvartanian3 天前原帖
我曾经认为,定义清晰的接口和服务之间的契约就足以维持模块化。我共享数据库,因为这似乎是最简单的选择。我错了。共享数据库或任何跨越外部组件边界的资源,会形成一种“焊接”连接,违背了任何接口定义。这会造成潜在的故障级联,随时可能发生。 许多工程师希望避免严格定义数据所有权所带来的摩擦。他们寻求一个礼貌的中立区域,以避免冲突。我认为这种做法在智识上是不诚实的。通过避免为了强制执行真正的模块化而必须进行的对抗,你构建的系统注定会在架构变化的那一刻崩溃。 我不得不通过艰难的方式学习到这一点。现在,我在每个组件的数据层强制严格分离。虽然这在前期更困难,但这是构建能够扩展而不至于在自身重压下崩溃的系统的唯一方法。如果你在共享数据库,或者以任何方式让你的领域数据跨越到外部模块,你就不是在构建一个模块化系统,而是在推迟不可避免的崩溃。
查看原文
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 &quot;welded&quot; 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&#x27;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.