07｜领域建模原理：DDD领域建模和传统方法有什么区别？
什么是领域模型？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
领域驱动设计（DDD）与传统方法的区别在于强调领域模型要兼顾业务和技术视角，反映了业务人员和技术人员的共识。模型驱动设计是DDD的核心模式之一，要求领域模型和业务需求一致，系统实现和领域模型一致。领域模型和业务需求一致需要通过业务人员和技术人员的协作完成，而系统实现和领域模型一致则意味着领域模型中的每个元素都应该在系统实现中有所体现。另一个核心模式是统一语言，要求业务和技术人员之间的语言是统一的，开发团队内部各角色之间的语言也是统一的。通过建立好领域模型、词汇表等“物质基础”，并在沟通协作的过程中不断保持模型、语言和系统实现的一致性，可以实现统一语言的理念。DDD的核心理念和模式为软件开发提供了一种围绕领域模型进行开发的方法，以确保系统实现与业务需求保持一致。
《手把手教你落地 DDD》，新⼈⾸单¥59
全部留言(25)
- 最新
- 精选
Jxin置顶
这章的认知和钟老师有挺大差异，我的观点不一定成熟，列出来，和大家共同探讨。 定调： 分析模型: 观察现实世界，记录现实世界的产物。模型产物: 用例分析/事件流。 设计模型: 对现实世界的认知做进一步提炼(抽象)的产物。模型产物: 领域模型图/ 架构设计/ 详设。 实现模型: 通过编码将设计模型中的概念转换成可运行的 代码/软件。 然后 分析->设计->实现 是一个循环关系（两关联一循环），这个循环会不断地增减和提炼知识。而领域建模指的是这个循环的产物，而不是单指分析阶段。也说明领域建模是一个循环渐进的过程，代码也是领域建模的一种模型产物。 为什么领域模型图是设计模型？ 首先为什么不是分析模型？ 因为领域模型里面的部分概念其实是做了抽象的，相比分析阶段的观察现实世界已经到了设计阶段的提炼和抽象；其次，以钟老师上章的UML图为例， 领域模型图既有领域模型以及模型间的关联关系，也有注释和规则，后面再追加领域服务与实体的行为，已经很完备，完备到可以用来验收和表达实现模型了（编码实现），这个粒度和能力从循环的顺序看，应该是落在中间的 设计模型。 思考题： 1.业务和技术理解不一致的情况很多，后果，可大可小，大部分偏小。毕竟系统都上了，还留有后果很严重的认知差异，这个还是比较少见的。毕竟我们哪怕不用ddd也不会不做风险设计和防患。毕竟一次资损整个团队一年白干。 2.做过，好几年，坚持下来了。不过在一线大厂时其实比较少用，1.团队不懂这块，自己的影响力也没法影响整个团队变更工作模式，所以权衡利弊，随大众。2.中台的系统，没有立场也没有勇气去做变更。（能了解到的信息很有限，基本只够在那加行代码，根本不敢乱来。为什么信息很有限，项目权限申请就直接劝退了）作者回复: 欢迎讨论！这是一个很有意思的问题，这里说一下个人的看法。 其实咱们的差异不在于事实上的差异，而是对概念定义的差异，也就是说，你所说的“分析/设计”和本课程所说的“分析/设计”的概念定义不同。后面的立论自然就不同了。就好比，一个天津人和一个广州人聊粽子。天津人说粽子是甜的，没有肉；广州人说粽子是咸的，有肉。这两个人永远无法统一，因为他们说的粽子不完全是一样东西。分析和设计这两个词的理解，业界本来就有歧义。 “分析”这个词，至少包含两层意思，一个是“需求分析”，一个是“系统分析”。 “需求分析”在UP里就简称“需求”，就是您所理解的“分析”，也就是记录现实世界的产物，相当于本课程中捕获行为需求的层面。 “系统分析”指的是对需求分析的结果进行抽象，产生领域模型。领域模型中仍然是业务概念，但是是经过抽象的。这就是本课程里的“分析”。 再说“设计”。有广义和狭义之分。 您所说的设计是广义的，也就是以“需求”（您所说的“分析”）的产出物为输入，得到整个解决方案的过程。其实“领域驱动设计”中的设计也是这种广义的理解。 本课程所说的设计是狭义的，也叫“系统设计”，指的是以“系统分析”的结果（也就是领域模型）为输入，产生系统设计模型（包含了业务人员不需理解的技术关注点）的过程。 换句话说，您所说的分析和设计的关系，相当于本课程所说的“问题空间”和“解空间”的关系。 本课程中“需求”、“分析”、“设计”三个概念，与UML三巨头的《统一软件开发过程》、Larmman的《UML和模式应用》以及潘加宇的《软件方法》基本上是一致的。您也可以参考一下。 总之，我们要把基本概念对齐，才有继续谈下去的基础。不知道我是否解释清楚了。
2022-12-29归属地：广东417
escray置顶开玩笑的说，我们的传统就是没有方法。 文中对于模型的定义和解释很精彩，特别是说模型以解决特定问题为目的。之前可能更多的把模型当做了可展示的三维模型，类似于沙盘；而对于计算模型，类似于图纸，考虑的比较少。 软件开发是建模过程，特别是业务系统，其实就是在使用技术手段模拟业务过程。之前参与过信息化系统的开发，试图使用技术来引领业务，比如超前开展无纸化办公，结果…… 曾经看到或者听说过得失败项目，大多数从第一步捕获行为需求就走歪了。 即使是传统软件开发，其实也希望能够站在技术和业务的十字路口。领域驱动开发，其实是给出了一种发现需求到分析设计的方法论，能不能用的好，就千人千面了。 领域模型和系统实现一致，并且能够保持同步进化，这个更难。 对于思考题， 1. 业务和技术理解不一致的地方，通常在于业务希望保持原有操作方式，越简单傻瓜不费脑子越好，技术希望能够分布式、微服务…… 2. 以前的项目主要是面向领导开发，所以谈不上领域建模，当然不排除领导本身是业务专家。作者回复: 读后感很赞👍🏻 思考题1的回答，我理解你是说了业务和技术的不同关注点，这种不同关注点常常最终引起对需求理解的不一致。
2022-12-22归属地：广东3
胡昌龙置顶感谢老师的内容，理得很清晰，很有帮助，请教下： 传统模式下，产品关注自己的业务分析模型，研发关注自己的技术设计模型，各自做好自己边界内的迭代维护工作。领域驱动模式下，领域模型，统一语言等也会不断迭代更新： 1) 如何在产品与研发是两个大部门的情况下，产品与研发一起同时维护更新，有没有相关的工具； 2) 另外，产品体系较大，模型和业务知识比较多的话，如何统一管理，快速构建可讨论画面 3) 每次迭代可能只是一个切面的需求，中间可能横跨多个领域，基于事件风暴及领域思路分析需求，会不会比较重，或者怎么做到轻； 感谢老师！！！作者回复: 1)首先是组织和沟通问题，最好进行产品化的组织转型（按产品把产品和研发划分到一个部门，共享KPI), 这超出了DDD的范围。如果动作不想太大，至少要让产品和技术理解沟通的价值，可以组成虚拟团队。其次是把DDD的动作融入到开发规范，产品和研发共同遵守。最好才是工具，一是产品和研发容易共享，二是做好版本控制。可以用Wiki，文件服务器、在线文档、Git等等。 2）划分限界上下文 3）不一定要用事件风暴，可以用任何能说明需求的方式，领域建模才是关键。
2022-12-20归属地：广东7
6点无痛早起学习的和尚这里有个疑惑点，其实很多时候，是不是只需要技术完成业务的功能就行了，比如业务你要什么功能，我技术按照我技术的设计（不按照业务的设计）帮你实现这个功能就行了，但是这个问题可能仅限于本次完成这个功能，导致了外表看起来一样，内在完全不一样。 如果后面业务基于这个功能要做新的扩展，技术的设计可能扩展性就不太好了，所以其实这里就是技术没有按照业务的设计去做，双方并没有达成内在设计去实现，最后就导致了这个冲突。 DDD 其实就可以解决掉这个冲突，不知道我理解的对不对。 因为我的工作中，就出现过，产品做了一个模型设计关系（账户模型），但是研发不按照产品的模型来设计，但是最终的功能出来是可以满足产品的。作者回复: 整体思路是对的。拿您现在的例子引申一下。如果虽然暂时满足了需求，但后来产品提了一个新需求，站在产品的角度，应该只需要系统改一点点就能实现，而开发却要大动干戈，那么设计模型八成有问题。反之，如果系统实现得正确，简洁，功能易扩展，那么可能是产品的模型不恰当。关键是，目前只有系统完成才能知道，有撞运气的感觉。DDD则让产品和开发在事前就把细微的概念理解通过模型一起搞清楚，达成一致，免得后面碰运气。
2022-12-29归属地：广东8
bighero我想谈谈我眼中的传统与现在的区别。 传统的时代是所谓的“两张皮”的时代。一面皮其实更倾向于拿过来用户需求就被开发人员按照ER关系割开来，拆解的七零八落的关系时代，代码只求crud的快活感。另一面皮是销售（当时并没有所谓的专职ba po划分）拿着cmm到处宣传讲解，某公司是多么按照国际标准规范来制作软件。 现在软件制作更倾向于mvp。最小实现小步快跑的方式螺旋迭代，利用小迭代来固化领域价值，不断迭代完善。所以才有了用户故事方式或事件风暴。其实我一直认为 事件风暴是一种特殊的用户故事表现形式。它力求从事件的起因 经过 结果，来反向导入who where when 。其实还是用户故事的一种描述方式而已。作者回复: 你看了事件风暴和故事的联系👍🏻
2022-12-21归属地：广东28
Michael还是有几个问题想请教老师，您说的DDD里的建模与普通建模的区别在于DDD里的建模需要兼顾业务和技术两种视角，但是在前面的例子里面似乎只专注于业务视角啊? 还有就是为什么在领域建模的时候要关注关系而不是别的东西呢？这个有没有什么说法之类的？作者回复: 1，这个问题很好，模型虽然兼顾业务视角，表现上却都是业务语言。现在的例子体现不出，第二迭代讲泛化时会提一下。 2，哲学上，认识事物最关键就是理解事物间的关系。。。
2022-12-21归属地：广东6
aoe看完之后豁然开朗，不在担心自己建模太烂，《DDD》序中写道“真正强大的领域模型是随时间演进的，即时是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法。” 在前几课一直纠结自己面对“企业管理”这个项目无法做到像老师一样的分析，现在的想法是，找一个自己感兴趣的项目开始练习 DDD 就完了。作者回复: 看来你是渐入佳境了 ：）
2022-12-20归属地：广东25- Geek_c33f40老师您好, 目前团队的开发流程是产品收集需求, 产品和交互输出交互稿, 我们开发按照交互稿的内容去实现就行了. 团队虽然有在落地DDD, 但领域模型还是只是开发去建模, 没有加上产品. 一方面是因为功能并不复杂, 开发通过交互稿就可以理解这个流程, 例如一个简单的包含发帖和回复的论坛. 另一方面产品对这个功能的理解也不深, 例如不清楚未来的规划, 功能拓展点可能在哪里, 都是走一步看一步, 所谓"敏捷", 加上产品也可能收效甚微. 目前问题在于设计领域模型的时候输入太少不太好做决策, 开发团队也尝试从例如竞品分析去获取更多对领域的理解, 但还是觉得不太够. 一个功能迭代次数太少也无法验证领域模型是否合理. 老师请问有没有什么好的建议? 还是说针对这种没有领域专家, 业务也相对简单的场景按现有的模式也是可以接受的, 领域模型应先按简单的方式做设计.
作者回复: 需要再深入了解您项目的具体情况才能给出有价值的建议。就我个人经验，这些问题还是由于没有深入掌握建模技能造成的，也就是说，领域模型不能真正反映深层的领域知识，所以效果就不大了。建议您根据后面的课程，把领域建模学得更深入一些，看看能否解决问题。您也可以把您的实际案例在咱们的交流群里讨论一下。案例越具体，我越能给出有效的建议。
2023-02-10归属地：广东3 
mm马本章内容与徐皓老师的两关联一循环有异曲同工之处，妙哉作者回复: 都是来自于同一源头😃
2023-02-04归属地：江苏3
leesper有个问题请教下钟老师：贵公司在完成需求分析、领域建模，进入设计和编码阶段时，是从头开始做，以TDD的方式进行演进式设计，一步一步迭代功能，添加一些必要组件（比如流程引擎）呢，还是在一些现成脚手架基础上直接做开发呢？我猜是前者，对吧？因为我对现在一些常用的脚手架其实是持保留意见的……这些所谓的脚手架拿来搞简单的CRUD可以，拿来实现复杂软件其实是处处掣肘，根本不好用的作者回复: 是的，基本是前一种。脚手架只是在编码阶段可能有些帮助。脚手架和整个DDD方法不在一个层面。
2022-12-20归属地：广东22
