该文章来自阿里巴巴技术协会（ ATA ）精选集 一些大的企业往往把域模型当作很重要的标准化和架构规划工具。 我在国外工作的十几年中，我曾经针对不同的场景参与开发了大规模域模型并且领导了基于域模型的研发，对域模型对团队甚至是整个行业的指导作用有一定的思考。 来到AliExpress后， 发现团队对域模型的理解不是很一致， 而应用就更少了。 所以在这里整理一份系统性的介绍， 帮助大家统一对域模型的认识，介绍一些基本的域模型整理思路。 通过这些介绍，期望整个技术团队能逐步把域模型应用到日常的架构规划和设计之中。 当然全面的介绍域模型可能需要写整整一本书。 但是这里假设读者是有数据建模背景的程序员，从而把介绍压缩成几篇文章。 第一篇主要介绍域模型的地位和作用。第二篇主要介绍域模型的主要概念，定义和表达。第三篇主要介绍域模型的设计和演化方法。第四篇主要介绍域模型的应用实例。第五篇介绍域模型设计中常见的误区。第六篇主要是我个人在域模型设计中的领会的一些要点和经验总结。 通过这六篇文章，期望大家能够意识到域模型对架构设计的重要性，并且能够真正掌握域模型设计的要点。 另外也期望通过这一系列文章， 能够引起大家对域模型的兴趣，一起深入研究。 什么是域模型？域模型（domain model）英文又称为问题域模型（problem space model）。维基百科(Wikipedia)对它的定义是” A conceptual model of all the topics related to a specific problem” 【6】. 可以翻译成： “域模型是针对某个特定问题的所有相关方面的抽象模型”。 这个定义有几个要点：第一是“特定问题”， 也即是说域模型是针对性某个问题域而言的， 脱离的这个特定问题，域模型的构建其实不存在一个最优或者是最合理的构建。 第二是抽象， 域模型是一个抽象模型， 不是对某个问题的各个相关方面的一个映射， 也不是解决方案的构建。 这一点我后续会展开来讲。 关于域模型， 经常会看到大家把逻辑数据模型(logical data model) 或者是物理数据模型(physical data model)和域模型混为一谈【5】。 甚至有同学把数据里的表结构抽取出来作为域模型来研究。 其实这是域模型的最大误区。 数据模型实质上都归属于结果域模型（solution space model）, 是对某个问题域的解决方案的一个描述， 实质上是对解决方案的一个具体描述。 另外一个常见的误区和领域驱动设计（DDD, Domain Driven Design）【2,3,4】有关。 我个人对DDD比较推崇， 但是DDD里提到的域模型实质上是结果域模型（Solution Space Model）, 不是问题域模型。 我在这个系列的文章里集中介绍的是问题域模型的构建， 而不是结果域模型的构建。这两者的区别在于前者的建立主要是为了统一我们对未知世界的了解， 也就是说我们需要统一思想， 搞清楚我们要解决什么问题和问题的本质。 而后者的主要是想解决针对近些年来敏捷开发模式中所普遍存在的对领域认知不完整而导致设计不合理的问题。 前者是一个对未知方向的探索过程，适用在一个相对较为模糊的命题，产出是对语言，边界和思路的统一。后者是一个方法论，适用于具体一个项目， 产出是一个项目的数据模型。 总结一下：（问题）域模型是为了准确定义需要解决问题而构造的抽象模型。 特别值得强调的是域模型的功能是统一认知：对要解决的问题有一个完整，规范，并且是一致的认识。 为什么我们要学习域模型呢？在阿里巴巴经常会听到一句话， “一颗心， 一张图，一场仗”。 我们做技术的同学要统一对这场仗的认知， 换句话说我们首先要明白要解决什么问题（仗）， 然后才能把这个问题毫无歧义的表述成一张图。 有了图，我们才能能够全心全意的投入到解决这个问题中去。
我们经常会发现， 在反复的争论之后， 我们往往对问题的定义还没有统一的认识。 所以这里我期望通过向大家介绍我们如何系统的，逻辑的，科学的定义我们的问题， 从而达到对我们要解决问题的统一认知。 这个过程就是问题域模型的建立。 域模型的价值之一，统一思想下面一张图其实是对域模型统一思想的功能的最好解释。这张图的名字叫“How Projects Really Work?", （具体作者不明，在http://projectcartoon.com/about/有备份）： 而域模型的核心价值在于统一项目中各个相关方对问题的认识， 从而避免此类问题发生。 这里我们需要强调域模型服务的对象是一个部门所有的成员。 也就是说整个部门需要对我们要解决的问题有统一认知， 而不只是技术团队内部或者是技术和产品团队的统一。 域模型的价值之二，团队分工和合作域模型的另外一个很重要的功能就是对一个技术团队的分工和合作方面的指导意义。 一个域模型，需要准确的定义需要解决的问题的方方面面， 这些问题的方方面面，就形成了我们对团队分工的理解。 域模型中的实体， 比如说商品， 店铺往往会演变成一些核心的数据， 而针对这些数据的管理系统会最终并存（co-locate）在同一个或是一组物理机房， 而围绕这些系统的设计，研发， 运维，运营，终端用户，和对终端用户的服务等等又会统一到同一批人中去， 也就是说这一批人有了共同的问题子域， 属于整个部门的问题域的一部分。不同于我们日常的从组织结构出发定义并解决问题的方法，我们对问题域的准确定义往往能够帮助我们找到组织结构中的弱点， 从而帮助我们建立最合适的组织结构或者是最合适的交流渠道。
域模型的价值之三，反映变化在电商领域里，随着消费人群需求，市场环境，和竞争对手的变化，我们所要解决的问题也在不断的变化。 举一个具体的例子， 我们一般都会定义生态系统的参与者。 最常见到的域模型定义里会有买家，卖家和小二。 随着时间进化， 因为运营流量， 我们需要引入联盟站长概念， 因为要引入第三方研发， 我们引入ISV概念， 因为要外包服务，我们需要引入定位和权限更细分的小二的角色， 等等。 而除了网站增长带来的变化， 电商业务的演变也会带来大的冲击。 比如说AliExpress,从B2B诞生，从C2C成长， 现在又逐渐转型做B2C。 这中间卖家业务从简单的提供信息，到支持交易， 到提供物流等服务，演变到和卖家紧密结合的supply chain integration. 这中间卖家的模型也在不断的演变。 而域模型就是真实反映这个变化的最好工具。
域模型在大型软件设计项目中的引入那么我们什么时候需要引入域模型呢？ 下图是一个非常好的解释。 这个图描述了软件错误的代价随着时间的变化趋势【1】。 这是个三维图。 第一维横轴是时间轴， 描述错误解决的时间。 第二维纵轴也是时间轴， 描述错误产生的时间。 第三维竖轴是解决错误所耗费的成本。 这张图里描述了四种情形， 第一种是代码错误， 发生在构建时间（construction）; 第二种是设计错误， 发生在设计期间（design）, 第三种是需求错误， 发生在具体需求产生的期间（requirement）, 第四种是概念错误， 发生在“concept of operations ”（一个对整个系统的概念性描述）形成的时间（ConOps）。 随着时间增长，解决错误的成本不断增长。 而这里面最大的成本就是概念的错误。 举个具体的例子， AliExpress在几年前最初形成卖家和店铺的概念的时候， 没有把卖家（Seller，aka Merchant）和店铺（Store）这两个概念分割开来。 而是简单的认为卖家就是店铺。 导致几乎所有的地方需要引用到店铺的情形都使用了SellerID。数据库，数据仓库，Service API 里到处都是SellerID， 而本该使用的是店铺ID， 这样的设计在一人一店的C2C时代还看不出大问题。 但是到了引入大的企业卖家，就出现很大的问题了。 因为一个企业卖家会同时开多个店铺。 店铺和企业是出现在完全不同的流程，服务，和数据分析中。 这个问题到最终解决可能造成的研发人日损失以千人日计。 所以我们一定要在一个项目最终形成概念的时候讨论域模型。 搞清楚我们需要解决的问题如何能够毫无歧义的表达出来。 这就是域模型的价值所在。 来源：云栖团队博客 原文：http://yq.aliyun.com/articles/2255# 转载文章，向原作者致敬！如有侵权或不周之处，敬请劳烦联系若飞（微信：1321113940）马上删除，谢谢！ END 本文转载自：微信公众账号 - 架构师，版权归原作者所有！ |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
