分块云计算

大模型或多或少要作一般化的处理，并因此失去上下文信息。

我个人强烈相信大的任务要一口一口地啃，而上下文是王道。

A前面说过，我认为建立企业数据模型的尝试常常以失败告终。现在我又发现一种有点讽刺的情形——还有项目几乎在重复同样的尝试，只不过这一次换成了“企业领域模型”。论据没变，我想结果和造成结果的原因也不会变……

公平来说，更常见的情况倒不是真的追逐“企业领域模型”，而是想建立单一的大型领域模型。此外，团队不时发现有需要切分大的领域模型，但又发现不容易找到满意的方案。

无论如何，我都强烈建议当领域模型出现增大迹象的时候，将它分块。还有别忘了模型是有上下文的。

很有趣，我还听闻一些非常大的SOA项目采取的第一个步骤就是打算建立一套“企业文档模型”。它会比企业数据/领域模型更成功吗？要是打赌的话，我宁愿下注在另一边。

整合数据库

就算有意避免巨型的单一领域模型，把模型隔离成几个部分，每一个部分还是有可能膨胀到相当规模。发生这种情况的时候，往往会发现数据库并没有分块。各个领域模型置于同一个数据库之上，也就是共用一个整合的数据库，见图3。

图3. 分块的领域模型，使用整合数据库

把多个领域模型置于单一数据库之上，只是整合数据库的其中一种情形。实际上跟多个独立应用共享同一个数据库是一样的。类似情况可谓屡见不鲜。

很不幸这样的安排给维护造成了极大的负担。任何影响到数据库Schema的改动都必须同步修改相应Schema的所有消费者。消费者越多，情况越糟。往往造成改动被限制到最低程度，很可能进而导致从代码中榨取的业务价值大大减少。