当前证据是否支持采用规范数据模型中的上下文？

“规范”思想在软件中无处不在。诸如Canonical Model，Canonical Schema，Canonical Data Model等模式似乎在开发中一次又一次出现。

像许多开发人员一样，我经常不加批判地遵循传统的常识，即需要规范的模型，否则您将面对映射器和翻译器的组合爆炸。或者至少，我用来做，直到几年前，当我第一次读到了几分臭名昭著的不信任投票EF：

曾经支持追求规范数据模型的假设既没有也不可能包含一旦将想法付诸实践就会发现的因素。通过多年的反复试验，我们发现针对每个单独的上下文使用单独的模型（可能在其中使用规范的数据模型）是最简单的方法，也是成本最低的方法，并且可以带来更大的可维护性和可扩展性使用上下文模型的应用程序和端点，并且这种方法不会像规范模型那样鼓励软件熵。

这篇文章没有提供任何证据来支持其主张，但是确实让我质疑CDM方法足够长的时间以尝试替代方法，并且所产生的软件在字面上或形象上都没有爆炸。但这并不意味着要孤立很多。我本来可以很幸运。

因此，我想知道，是否对软件系统或体系结构中的规范模型与上下文模型的实际，长期影响进行了认真的研究？

或者，如果现在提出这个要求还为时过早，那么有没有任何开发人员/架构师撰写过有关从CDM切换到独立上下文模型（反之亦然）的个人经验的书，以及对生产率，复杂性或可靠性等方面的实际影响是什么？

那么在不同级别上的差异又如何呢？也就是说，在单个应用程序中使用同一模型与在应用程序系统或整个企业中使用模型之间的差异呢？

（请只提供事实；欢迎战争故事，但不能no测。）

为了回应EF不信任投票，Tim Mallalieu写道：

我们不建议人们回到我们宣传将XSD用于“规范模式”的时代。我不相信人们认为这很容易处理。但是，我们确实希望有一个单一的元模型（如果需要的话，可以使用EDM），您可以用它描述许多领域模型，并且通过一个单一的语法，我们可以在任何一个模型上提供一套通用服务给定的领域模型。

例如，考虑要针对具有600个表的数据库编写的应用程序。我是否认为该应用应该具有600种实体类型的单一模型？否……此外，我是否相信任何给定的域实体（例如客户）在该应用程序中都只有一个形状，并且该形状必须是整个企业的规范形状？

Wikipedia上有关规范模型的文章引用了诸如Enterprise Service Bus，面向服务的体系结构和CORBA之类的东西，这些东西似乎几乎不再被谈论。它们全都构成了解决企业数据扩散和通信挑战的解决方案，“ 一环统御”。^TM 他们成功了吗？还是他们在自己的体重下崩溃了？

您要求个人经历，所以我给您一个。在航空航天行业，我们经常使用遥测技术。遥测系统的挑战之一是找到一种方法，使不同的测试范围以有意义的方式相互传递测试数据。在您尝试定义通用术语的数据字典之前，这个问题似乎很简单。

“海拔”是什么意思？是高于地面的高度，还是高于海平面的高度？如果您正在谈论潜水艇怎么办？然后是它的深度，而不是高度。对陆军而言，“传输”一词在指雷达碟时的含义与对地面车辆的含义不同。导致飞机滚动的机翼表面在某些飞机上称为“空中”，在另一些飞机上称为“ elevon”。

这只是随之而来的众多问题的暗示。尽管存在数据通信的标准，但是每个测试范围都不同，并且具有不同的需求，目标和优先级。即使同一范围内的不同项目之间的标准也可能不同。因此，测试范围可以理解，解决方案不是通过用单个整体式系统来代替所有内容，而是通过就简单的通信协议达成共识并提供从一个范围的词汇转换为另一范围的词汇的方式来解决的。

大公司面临的问题是相似的。微软倾向于以整体的方式来思考，但这是因为他们的公司总体上是整体的。一旦您需要在具有截然不同的文化和经营方式的不同公司之间（甚至在同一公司的各个部门之间）进行沟通，就可以一劳永逸。^TM立即开始崩溃。