你好，我是钟敬。
前面几节课，我们一起完成了行为需求和领域建模，重点在于实践。但是，如果仅停留在实践层面，不去了解背后的原理，我们就会知其然而不知其所以然，最终还是不能很好地进行实践。
所以，在对领域建模有了一定的感性认识以后，今天我们上升到理论层面，一起来理解模型驱动设计的本质含义。然后再来深入探讨“统一语言”，以及它和领域建模的关系。
什么是领域模型？
在讨论什么是领域模型之前，咱们先说说什么是模型。
先来看几个例子。比如说你去买房，售楼处都会有一个沙盘模型，这样你就可以看到楼的外观、朝向、周边环境等等。
但是如果要盖这个楼盘，靠沙盘模型就不行了，需要有一套详细的建筑图纸，图纸也是模型。为了对大楼进行设计，还要进行各种计算，计算用的公式也是模型，称为数学模型。另外，小孩玩的玩具车、玩具枪什么的，也是模型。事实上，现代生产和生活中，充满着各种各样的模型。
从这些例子里，咱们可以发现模型的几个共同特点。
首先，模型是以解决特定问题为目的的。例如沙盘模型是为了卖房，而建筑图纸是为了盖楼。没有目的就谈不上模型。
第二，模型都是对现实世界或人们思维中的事物进行的模拟。例如沙盘模型和建筑图纸都是对建筑物的模拟，而玩具车是对真车的模拟。
第三，模型总是提取了被模拟事物中的部分信息，而忽略掉了其他大部分信息。例如，沙盘模型提取了楼盘的外观信息，但是忽略了内部结构和建筑材料信息。而建筑图纸反映了内部结构信息，但忽略了外观信息。到底提取哪些信息，忽略哪些信息，取决于模型的目的。
第四，模型可以有多种表现形式，例如图纸、影像、公式以及电脑中的文件等等。具体采用哪种形式，取决于要解决的问题和当前的技术水平。
最后，模型是一种人造物，大自然本身是不存在模型的。
软件开发是一个建模过程
说到这儿，不知道你发现了没有？其实计算机软件也是一种模型。这是因为，计算机软件也是为了满足业务需求，对现实世界的事物和逻辑进行的模拟。所以，我们开发计算机软件的过程也是一个建模过程。
软件本质上是运行在机器上的一串二进制流，我们姑且称之为“机器模型”。我画了一张图，表示了现实世界和机器模型之间的关系。
我们看到，在机器模型和丰富多彩的现实世界之间存在着巨大的鸿沟，所以，用二进制直接为现实世界建模是非常困难的，这也是软件开发如此困难的原因之一。
那么，如何克服这一障碍呢？打个比方，假如我们想爬到房顶上去，太高了上不去怎么办，那就搬个梯子，一步一步地爬上去。
软件开发的道理是一样的。可以把由现实世界到机器模型的过程分成几步，一步一步地走。传统软件工程中，从现实世界到机器模型的过程，一般是这样的：
第一步是捕获行为需求，研究为了满足业务需求需要有怎样的流程和功能，可以用传统的用例分析来做，也可以用咱们这里的事件风暴。
第二步是分析，在行为需求的基础上，对现实世界中领域知识或者说业务概念进行分析和提炼，形成分析模型。尽管分析模型反映的仍然是业务概念，然而是经过抽象得来的，更加严谨、精练和一致，因此比行为需求更加接近实现。
第三步是设计，在分析模型的基础上，增加技术关注点，进行架构设计、详细设计、数据库设计等，形成设计模型。设计模型介于分析模型和代码之间。
第四步是编写代码。代码经过编译后，就成为了运行在机器上的“机器模型”了。
其实，第二步中的分析，就是对领域知识的抽象和提炼的过程，所以分析模型也可以称为领域模型，这个过程也可以叫做领域建模。
但是，很多伙伴在开发软件时，并没有经过领域建模这一步，而是直接进行设计和编码。如果是简单系统的话还可以，如果是复杂系统，就会出现很多问题了。
DDD领域模型与传统方法的不同之处
看到这儿你可能会问了，既然传统软件工程也有领域模型，那DDD的领域模型与传统的方法又有什么不同呢？
这两者之间有一个重要区别：DDD强调领域模型要兼顾业务和技术两个视角。
在传统软件工程里，建立分析模型强调完全从业务领域出发，不考虑技术视角。然后，才会把分析模型交给技术专家，转化为设计模型。两者的关系如下图：
这种方法虽然在理论上是完备的，但实践中常常会有问题。由于在分析阶段没有从技术视角考虑，那么在转化为设计模型的时候，就可能发现有些分析模型很难实现，需要通过复杂的转换，才能适应软件开发的要求，因此两种模型之间就产生了比较大的差距。
所以，在之后的开发过程中，开发人员往往只是聚焦于设计模型，而将分析模型束之高阁。时间久了，分析模型与系统实现之间的差异越来越大，也就失去了存在的意义。最终，技术实现与业务越来越远，软件系统也就难以真实反映业务需求了。
但是，DDD的领域模型则是业务视角（原来的分析模型）和技术视角（原来的设计模型）的交集。它反映了业务人员和技术人员的共识。
尽管技术人员仍然要为领域模型增加实现细节，形成设计模型，但设计模型必须严格遵循领域模型。对领域模型的修改，必须由业务和技术双方达成一致。这样，就避免了传统软件工程中分析模型和设计模型相互割裂的风险，如下图：
为了表达DDD的侧重点，我们把传统的软件开发过程修改为下面这样：
在这个图中，我们直接用领域建模代替了原来的分析步骤。同时，把原来的设计和编码合并成了模型的实现，这是因为，从敏捷的角度来看，设计和编码常常会融合在一起。
模型驱动设计
围绕领域模型进行开发的方法，在DDD中称为模型驱动设计（Model-Driven Design），是DDD的核心模式之一。这个模式可以概括为两点：
- 领域模型要和业务需求一致；
- 系统实现要和领域模型一致。
领域模型要和业务需求一致
首先我们来看看领域模型和业务需求一致。
DDD非常重视对业务需求中领域知识的消化。虽然我们从事件风暴就开始消化了，但领域建模才是消化知识的核心。在这个过程中，事件风暴里遗留的不清晰的部分会得到解决，并且还会发现新的知识。
事实上，事件风暴和领域建模有一个重要的区别：事件风暴仅仅追求“形似”，也就是说业务是怎样运作的，事件风暴就怎样反映。
而领域模型不仅要和需求“形似”，更要“神似”。也就是说，领域模型不仅要对业务进行直观模拟，更要经过提炼，形成浓缩的知识。
什么意思呢？这里主要是指两点，
第一点，是通过抽象思维得到更“深刻”的模型。比如说，我们从企业、开发中心等概念中抽象出组织和组织类别，从人事人员、销售人员中抽象出岗位等等。这使模型中的知识不再停留在业务的表面，而是深入到业务的本质，有利于开发出更加灵活简洁的系统。
第二点，是通过深入思考得到更“丰富”的模型。比如说，我们通过分析“取员工上级”的操作，识别出了员工和组织之间关于组织负责人的关联。另外，作为领域知识的一部分，我们还补充了更多的业务规则，这些都使模型更加丰富。蕴含丰富知识的领域模型，可以让我们在开发的时候不容易遗漏重要的领域概念和规则。
另外，领域模型和业务相一致，必须通过业务人员和技术人员的协作才能完成。业务人员的参与，能为领域模型带来专业的领域知识，而技术人员可以为领域模型带来更高的抽象性和严谨性。
而且，技术视角的加入还为领域模型的选择提供了参考。前面我们说过，模型是一种人造物。既然是人造的，就会带入主观因素，对于同一业务，可能会构建出不同形式的领域模型，这些模型可能都“对”，关键在于哪一个“更好”。这时候，技术人员从技术视角出发，往往可以发现，有些模型更容易进行技术实现。所以，尽管领域模型中都是业务概念，却可以通过技术视角选出更恰当的模型。
系统实现和领域模型一致
模型驱动设计的第二个要点是系统实现和领域模型一致。
如果修改了领域模型，那么系统实现必然也要修改；反之，如果系统实现发生了变化，也很有可能导致模型的变化。
这背后还隐含了一个推论：领域模型中的每个元素，都应该通过某种方式在系统实现中有所体现。反过来说，如果发现领域模型中的某个元素不需要落实到实现里，那么就应该在领域模型里删除这个元素。这也是技术人员参与到领域建模中的一个原因。
根据领域模型进行系统实现的具体技术，我们在会后面的课程中介绍。
领域模型和业务需求一致、系统实现和领域模型一致，最终结果就是系统实现和业务需求总是一致的，避免了系统实现和业务需求差距越来越大，这个老大难问题。
领域模型与统一语言
除了模型驱动设计以外，DDD中的另一个核心模式是统一语言（Ubiquitous Language）。
统一语言包含了两个层面的含义：一是业务和技术人员之间的语言是统一的，二是开发团队内部各角色之间的语言是统一的。最终结果就是每一行代码都能对应到统一语言，从而与业务保持一致。你可能已经发现了，统一语言和领域模型的目的是一致的。
统一语言的概念其实很容易理解，难点在于怎么真正在实践中贯彻。
要在实践里真正贯彻“统一语言”的理念，我们可以从统一语言的“物质基础”和“实际应用”这两个方面来考虑。领域模型、和词汇表（glossary）和业务规则表等文档性的制品，就是统一语言的“物质基础”。而业务和技术人员在开发过程中的沟通协作，就是统一语言的应用。
这两方面缺一不可。要用好统一语言，首先要建好领域模型、词汇表和业务规则表。没有这些，就无法对语言进行规范化和持久化。
另一方面，在所有的协作过程中，每当我们说到领域知识的词汇，都要看一下在领域模型中是否有所反映、大家对同一概念的理解是否一致、已经废弃的词汇是否还在使用等等。
如果发现语言与模型不一致，就要及时纠正，让两者恢复一致。编写代码的时候，也要使代码中的各种命名与模型和词汇表保持一致。在前面的课程里，咱们在建模中模拟了你我两人的对话过程，就是希望你能够体会到语言在沟通中的应用。
在领域建模的过程中，我们也强调了，实体、关联等元素翻译成自然语言应该怎么说。事实上，好的模型中的任何元素，都应该可以和自然语言进行顺畅地双向转换。
总结
这节课的主要内容就讲完了。我们来总结一下。
今天我们首先介绍了模型的概念，然后说明了软件开发也是一个建模过程。为了跨越现实世界和机器模型之间的鸿沟，人们采用了“分步走”的方式。其中，在传统软件工程中的分析步骤产生的分析模型，也叫做领域模型。
但是，DDD的领域模型与传统软件工程有一个重要的区别，就是，DDD强调领域模型要兼顾业务和技术两个视角，而不像传统方法那样，只关注业务视角。
所以，我们可以说：DDD的领域模型是为了满足业务需求，对领域知识进行提炼和抽象的产物，反映了业务和技术人员的共同视角。一方面，它能够全面和深刻地反映领域知识，另一方面又能方便地转化为技术实现。
DDD的核心模式之一：模型驱动设计就是围绕领域模型展开的。它有两个要点：领域模型和业务需求要保持一致；系统实现和领域模型也要保持一致。最终的结果就是系统实现和业务需求保持一致。
除此之外，DDD还有另一个核心模式：统一语言。要用好统一语言，一方面要建立好领域模型、词汇表等“物质基础”，另一方面要在沟通协作的过程中，不断保持模型、语言和系统实现的一致性。
这节课理论比较多，可能比较抽象，希望你在实践中不断体会。
思考题
1.在你的实际项目中，有没有遇到过业务和技术理解不一致的情况，造成了什么后果？
2.在你的实际项目中，有没有做过类似领域建模的事情，是否能够坚持下来？
好，今天的课程结束了，有什么问题欢迎在评论区留言，下节课，我们开始过渡到模型的实现，讲一下怎样根据领域模型进行数据库设计。
精选留言
2022-12-29 20:32:59
定调：
分析模型: 观察现实世界，记录现实世界的产物。模型产物: 用例分析/事件流。
设计模型: 对现实世界的认知做进一步提炼(抽象)的产物。模型产物: 领域模型图/ 架构设计/ 详设。
实现模型: 通过编码将设计模型中的概念转换成可运行的 代码/软件。
然后 分析->设计->实现 是一个循环关系（两关联一循环），这个循环会不断地增减和提炼知识。而领域建模指的是这个循环的产物，而不是单指分析阶段。也说明领域建模是一个循环渐进的过程，代码也是领域建模的一种模型产物。
为什么领域模型图是设计模型？ 首先为什么不是分析模型？ 因为领域模型里面的部分概念其实是做了抽象的，相比分析阶段的观察现实世界已经到了设计阶段的提炼和抽象；其次，以钟老师上章的UML图为例， 领域模型图既有领域模型以及模型间的关联关系，也有注释和规则，后面再追加领域服务与实体的行为，已经很完备，完备到可以用来验收和表达实现模型了（编码实现），这个粒度和能力从循环的顺序看，应该是落在中间的 设计模型。
思考题：
1.业务和技术理解不一致的情况很多，后果，可大可小，大部分偏小。毕竟系统都上了，还留有后果很严重的认知差异，这个还是比较少见的。毕竟我们哪怕不用ddd也不会不做风险设计和防患。毕竟一次资损整个团队一年白干。
2.做过，好几年，坚持下来了。不过在一线大厂时其实比较少用，1.团队不懂这块，自己的影响力也没法影响整个团队变更工作模式，所以权衡利弊，随大众。2.中台的系统，没有立场也没有勇气去做变更。（能了解到的信息很有限，基本只够在那加行代码，根本不敢乱来。为什么信息很有限，项目权限申请就直接劝退了）
2022-12-20 08:57:32
传统模式下，产品关注自己的业务分析模型，研发关注自己的技术设计模型，各自做好自己边界内的迭代维护工作。领域驱动模式下，领域模型，统一语言等也会不断迭代更新：
1) 如何在产品与研发是两个大部门的情况下，产品与研发一起同时维护更新，有没有相关的工具；
2) 另外，产品体系较大，模型和业务知识比较多的话，如何统一管理，快速构建可讨论画面
3) 每次迭代可能只是一个切面的需求，中间可能横跨多个领域，基于事件风暴及领域思路分析需求，会不会比较重，或者怎么做到轻；
感谢老师！！！
2022-12-22 15:12:39
文中对于模型的定义和解释很精彩，特别是说模型以解决特定问题为目的。之前可能更多的把模型当做了可展示的三维模型，类似于沙盘；而对于计算模型，类似于图纸，考虑的比较少。
软件开发是建模过程，特别是业务系统，其实就是在使用技术手段模拟业务过程。之前参与过信息化系统的开发，试图使用技术来引领业务，比如超前开展无纸化办公，结果……
曾经看到或者听说过得失败项目，大多数从第一步捕获行为需求就走歪了。
即使是传统软件开发，其实也希望能够站在技术和业务的十字路口。领域驱动开发，其实是给出了一种发现需求到分析设计的方法论，能不能用的好，就千人千面了。
领域模型和系统实现一致，并且能够保持同步进化，这个更难。
对于思考题，
1. 业务和技术理解不一致的地方，通常在于业务希望保持原有操作方式，越简单傻瓜不费脑子越好，技术希望能够分布式、微服务……
2. 以前的项目主要是面向领导开发，所以谈不上领域建模，当然不排除领导本身是业务专家。
2022-12-21 22:51:40
传统的时代是所谓的“两张皮”的时代。一面皮其实更倾向于拿过来用户需求就被开发人员按照ER关系割开来，拆解的七零八落的关系时代，代码只求crud的快活感。另一面皮是销售（当时并没有所谓的专职ba po划分）拿着cmm到处宣传讲解，某公司是多么按照国际标准规范来制作软件。
现在软件制作更倾向于mvp。最小实现小步快跑的方式螺旋迭代，利用小迭代来固化领域价值，不断迭代完善。所以才有了用户故事方式或事件风暴。其实我一直认为 事件风暴是一种特殊的用户故事表现形式。它力求从事件的起因 经过 结果，来反向导入who where when 。其实还是用户故事的一种描述方式而已。
2022-12-29 10:03:41
如果后面业务基于这个功能要做新的扩展，技术的设计可能扩展性就不太好了，所以其实这里就是技术没有按照业务的设计去做，双方并没有达成内在设计去实现，最后就导致了这个冲突。
DDD 其实就可以解决掉这个冲突，不知道我理解的对不对。
因为我的工作中，就出现过，产品做了一个模型设计关系（账户模型），但是研发不按照产品的模型来设计，但是最终的功能出来是可以满足产品的。
2022-12-21 22:02:06
还有就是为什么在领域建模的时候要关注关系而不是别的东西呢？这个有没有什么说法之类的？
2022-12-20 22:23:29
在前几课一直纠结自己面对“企业管理”这个项目无法做到像老师一样的分析，现在的想法是，找一个自己感兴趣的项目开始练习 DDD 就完了。
2023-02-10 00:02:46
团队虽然有在落地DDD, 但领域模型还是只是开发去建模, 没有加上产品. 一方面是因为功能并不复杂, 开发通过交互稿就可以理解这个流程, 例如一个简单的包含发帖和回复的论坛. 另一方面产品对这个功能的理解也不深, 例如不清楚未来的规划, 功能拓展点可能在哪里, 都是走一步看一步, 所谓"敏捷", 加上产品也可能收效甚微.
目前问题在于设计领域模型的时候输入太少不太好做决策, 开发团队也尝试从例如竞品分析去获取更多对领域的理解, 但还是觉得不太够. 一个功能迭代次数太少也无法验证领域模型是否合理.
老师请问有没有什么好的建议? 还是说针对这种没有领域专家, 业务也相对简单的场景按现有的模式也是可以接受的, 领域模型应先按简单的方式做设计.
2023-02-04 22:46:14
2022-12-20 22:00:21
2022-12-20 11:12:47
2022-12-20 09:01:35
2. 习惯先建模再设计以后，就回不去了
2023-04-27 08:10:27
在实践中，产品经理给的业务需求在某个功能上/模型上就是一句话的内容，写的很粗，当研发看到这句话进行了自己的一些抽象设计模型，然后 PM 就不认可这个抽象模型和他的业务需求模型不一样，但是研发的抽象模型比PM 的业务需求模型更抽象，扩展性也更强，研发的抽象设计模型也能完成满足 PM 当前业务需求和未来扩展的需求场景。
就因为这个点，研发和 PM 撕逼了不少次，研发吐槽 PM 过度干涉技术设计，PM 吐槽研发不按照需求来。
具体🌰就是这样：
背景：我们是做一个海外电子银行的业务，模型就是三户模型，底层是资金账户概念
PM需求：来一个人，我要给这个人开设一个账户，账户类型就是现金户，对应的就是资金账户类型里的余额账户，也就是 type+人==>余额账户
研发设计：把账户类型设计成一个模型叫产品账户概念，1 个人可以有多类产品账户，1 个产品账户有多个资金账户，抽象原则就是：分离开业务层和资金层，业务层可以多变，资金层永远是不变的。
就因为这个设计，互相撕逼不认可。其实现在来看，研发是把产品诉求里的类型抽象了一个模型，而产品就理解为一个字段。
2023-02-03 16:32:23
2024-11-16 14:13:09
2024-05-16 15:19:58
2024-04-16 16:51:59
DDD 中的核心模式：统一语言、模型驱动设计
建立领域模型是 DDD 的核心，主要有两个目的：
将知识可视化，准确、深刻地反映领域知识，并且在业务和技术人员之间达成一致；
指导系统的设计和编码，也就是说，领域模型应该能够比较容易地转化成数据库模式和代码实现。
请根据 彼得·德鲁克的《管理》一书，分析一下「知识在 DDD 中的作用」 AI 总结：
领域模型本质上是对领域知识的抽象和表达
知识是决策的基础
知识创造价值
知识的共享与沟通
持续学习与知识的迭代
知识的管理与领导
使知识具体化并可操作
知识在 DDD 实践中的体现：事件风暴、领域建模
知识管理的内容来自 《徐昊 · AI 时代的软件工程》课程
详见 https://wyyl1.com/post/23/09/
2023-10-17 11:03:47
2023-10-07 15:21:54
2、我们BA有做过，但是因为整个业务流程过于复杂，每个开发只能兼顾到自己对应的那部分，所以对整个模型的理解并不是很通透，只是对对应的每个us理解比较多。
2023-06-08 19:25:44