BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

避免标准数据模型

| 作者 Jan Stenberg 关注 34 他的粉丝 ,译者 邵思华 关注 3 他的粉丝 发布于 2015年4月15日. 估计阅读时间: 2 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

将企业软件中进行数据交换的业务对象,例如客户、订单或产品等常规模型进行标准化,让它们包含所有属性与关联信息,这种做法看上去似乎是一种吸引人的目标,但在Stefan Tilkov看来,这种方式将产生标准数据模型(Canonical Data Model - CDM),这是一种十分糟糕的做法,他强烈建议不要这么做

Tilkov是innoQ的联合创造人兼首席顾问,在他多年的经验中,无数次地看到各个软件组织是怎样基于错误的假设而进行工作的。他同时表示, 他所定义的CDM这种模型会使得组织必须进行大量的会议、并且需要所有相关人员参与协作。通常来说,这种方式所产生的模型中包含了大量的可选属性,以及为了满足所有系统对该模型的不同需求和制约而编写的各种奇怪行为。

为了避免产生这种模型,Tilkov推荐的方式是使用边界上下文,这个概念来自于领域驱动设计(DDD)。它是想法是将一个巨大的模型划分为多个小的上下文,因此在不同上下文中的业务对象可以根据每个上下文的不同需求,采取不同的建模方式。他同时强调,这一点不仅对于大型系统来说非常重要,对于企业范围的架构来说更是至关紧要,因为每个系统都具有不同的需求,应当根据各自的需求不同进行相应的设计。

对于那些仍然以CDM为目标的组织,Tilkov提供了一些指南,以应对各种可能出现的问题:

  • 允许在系统中使用独立的特定模型,可以由不同的团队定义模型中的不同部分。
  • 对模型格式进行标准化,并创建结构小于业务对象的构建块,而不是一个巨大的、一致的模型,因此多个团队可以按照他们的需求共同添加这些构建块。
  • 不要将模型强行推给团队,如果团队认为在他们的上下文中使用这个模型能够带来某些价值,让团队自己选择将该模型引入。

在Tilkov看来,企业架构师应当避免集中式的模型与CDM,而应当尽量将整体性的内容减至最低,将大部分职责交给团队本身及团队中的成员。

在2008年,Bill Poole在一篇文章中从SOA的角度对集中式非集中式模型进行了对比。在他看来,集中式的模型中存在着许多缺点,从他的自身经验来看,他更倾向于使用非集中式的模型,这一观点也引起了人们的一些争议

查看英文原文:Avoid a Canonical Data Model

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT