将企业软件中进行数据交换的业务对象，例如客户、订单或产品等常规模型进行标准化，让它们包含所有属性与关联信息，这种做法看上去似乎是一种吸引人的目标，但在 Stefan Tilkov 看来，这种方式将产生标准数据模型（Canonical Data Model - CDM），这是一种十分糟糕的做法，他强烈建议不要这么做。
Tilkov 是 innoQ 的联合创造人兼首席顾问，在他多年的经验中，无数次地看到各个软件组织是怎样基于错误的假设而进行工作的。他同时表示， 他所定义的 CDM 这种模型会使得组织必须进行大量的会议、并且需要所有相关人员参与协作。通常来说，这种方式所产生的模型中包含了大量的可选属性，以及为了满足所有系统对该模型的不同需求和制约而编写的各种奇怪行为。
为了避免产生这种模型，Tilkov 推荐的方式是使用边界上下文，这个概念来自于领域驱动设计（DDD）。它是想法是将一个巨大的模型划分为多个小的上下文，因此在不同上下文中的业务对象可以根据每个上下文的不同需求，采取不同的建模方式。他同时强调，这一点不仅对于大型系统来说非常重要，对于企业范围的架构来说更是至关紧要，因为每个系统都具有不同的需求，应当根据各自的需求不同进行相应的设计。
对于那些仍然以 CDM 为目标的组织，Tilkov 提供了一些指南，以应对各种可能出现的问题：
- 允许在系统中使用独立的特定模型，可以由不同的团队定义模型中的不同部分。
- 对模型格式进行标准化，并创建结构小于业务对象的构建块，而不是一个巨大的、一致的模型，因此多个团队可以按照他们的需求共同添加这些构建块。
- 不要将模型强行推给团队，如果团队认为在他们的上下文中使用这个模型能够带来某些价值，让团队自己选择将该模型引入。
在 Tilkov 看来，企业架构师应当避免集中式的模型与 CDM，而应当尽量将整体性的内容减至最低，将大部分职责交给团队本身及团队中的成员。
在 2008 年，Bill Poole 在一篇文章中从 SOA 的角度对集中式与非集中式模型进行了对比。在他看来，集中式的模型中存在着许多缺点，从他的自身经验来看，他更倾向于使用非集中式的模型，这一观点也引起了人们的一些争议。
查看英文原文： Avoid a Canonical Data Model
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论