03｜我们要怎么理解领域驱动设计？

上一课我的回答基本都在这一课中得到了验证，看来我的理解和主流观点应该没有太大偏差，老师总结得还是更到位！ 在大约9年多的学习和实践中（旧约实践，非常期待你的新约课程），我遇到的最大的问题应该是模型变更前后数据迁移成本较高，必须是人工迁移，并且生产环境无缝迁移基本不可能。 另外我自己做甲方的时候，模型都给他分析出来了，乙方不愿意配合实现模型（都告诉他其实我是在为他节约开发成本）。倒是做乙方的时候，甲方一般都还是比较能够接受这种方式。 再有，建模真的很依赖于建模人员的抽象能力。你无法交给能力一般的开发人员去做。这种人才太少了，人才稀缺算是DDD的缺点么^_^

关于内容： 只谈责权行动是难以维持的。责权利心法，责任权利利益必须匹配。 关不关心生产实现，对于业务方是一场无悬念的博弈。 关心了，成效很模糊，但累和困难很明确。因为我除了自己的业务还要学习开发定义的业务概念（学习/沟通成本），同时描述业务故事也得基于这些概念来沟通（约束），搞错了我还有责任。而好处也许能大大加快我后续功能的迭代，甚至像发现宝藏一样洞察新的方向，但是这些感觉很遥远，所以我对它估值很模糊； 不关心，风险模糊，轻松无责明确。因为我只需要关注自己的业务，对于开发只需要提出我要什么，如果有问题也是开发的实现不符合或者达不到我的期望，这样工作就很单纯和轻松，便于专注业务做出更好的成绩。而风险就是软件质量差，后续迭代缓慢甚至改不动，越往后线上bug概率越高，这些就有点远了，所以它很模糊，毕竟我也不知道明天是不是还是我负责这块业务，为它付出成本贴现率很低。 如上，如果无法洞察业务方的利益点，并以利牵头，这样的博弈基本没有悬念。怎么办？ 1.放大风险，强调系统异常带来的危害。幸幸苦苦干一年，一朝资损全年白干。 2.拉近价值，如果按这个方式配合，我们就给你开通排期绿色通道。 3.领导支持，拉领导拍案，并非以势压人，而是为他人搭建发挥的舞台。 课后题： 关联模型与软件实现我说两个难点： 1.代码模型透出。 2.模型变更与代码变更必须保证原子性。 YY处理： 1.代码模型透出： （1）提供接口依赖树查看能力（可以看出部分关联关系） （2）提供代码映射模型的能力。设置定义模型的注解，然后用注解标注代码，启动时基于注解生成对应的模型文档。 2.模型变更与代码变更必须保证原子性 （1）在CICD流水线创建实例时要求而外关联一个模型变更需求，必须由项目负责人CR模型文档确实同步了当前变更才能执行流水线。（在流程制度上加环节，且责任到人） （2）最理想的状态，代码既模型，模型既代码。web界面实施模型会直接生成代码，改动对应代码会直接反应到web界面的模型上。模型与代码自动联动。

看到关于权责的论述的部分时脑海里浮现出一个疑问，就和让业务和技术双方都接受这个权责分配？很多时候，业务方只关心结果，其实没有意愿“享受”“影响软件实现”的权利，因此，就没有意愿承担相应的义务。本课后半程也提出了这样的问题，“如何推动业务方更主动地参与提炼知识的循环？” 。万事开头难，这个可能是架构师在推动DDD落地过程中首先可能所遇到的坎——如何有效的启动知识消化的循环？这块可能和DDD的核心关系不大，不过也希望老师能分享一下一些经验😀。

某知识服务商有一道考验新人试题，请说说怎么解读《新华字典》。 如果采用总结提炼划重点方法，你说它的重点在哪儿？哪个字重要，哪个字不重要？它的结构是完全平铺的，没有重点。 但是从问题出发，看看一部字典为我们解决了什么问题，那角度就比较多了。 个人的一点浅见要从业务想要解决的实际问题出发来找出包含在其中的知识，感觉领域和问题是一体的两面。

领域驱动设计，理解就是为了将具体的业务场景以及开发所要实现的代码结构，通过‘说人话’的方式进行呈现。如何‘说人话’（领域驱动设计），应该就是： 1、将业务场景通过‘完全穷举、相互独立’的方式列举出来； 2、将列举出的场景通过抽象的方式，将实体之间的关系进行展示； 输出第1、2点的内容后，不断与业务、技术一起进行探讨，保证正确且无遗漏， 最终得出的，就是我们的‘模型’。 不知道理解的是否对，请老师指教！

看完这一讲，突然想起来之前做金融类系统，需求文档开头会把涉及的概念和术语定义出来，我觉得这个应该算是最初版本的统一语言。

怎么把实体合理分成多个聚合。判断实体属于一个聚合的标准是什么

请教一下老师 Ubiquitous language 和 Domain Specific Language 有什么区别和联系？

回答思考题，模型本身是与技术无关的，但软件实现是受限于技术选型的，因此有可能出现模型不能很好的用所选技术直接实现，或技术本身的最佳实践会给模型引入一些新的概念，进而丰富统一语言，如观察者，访问者等等可能业务方需要适应的概念。 解决方法，我觉得还是权衡吧，如果技术对模型的反馈是大家都能够理解并接受的，未尝不可；但如果模型无法直接实现，可以选用技术工具弥补不足，也许也可以使用。比如模型直接实现有性能问题，可以使用cache layer解决性能问题，从而保证模型的简洁和高效

可能的困难：业务能力差，技术人员不懂业务。业务方能力差，可以请一些业务专家来支持；技术人员不了解业务，组织一些专题培训，多向业务人员请教，不一定所有技术人员都要很懂业务，但是核心技术人员一定要懂，否则大概率会出问题。我是做外包项目的，基本是二次开发，业务功能通过现有的系统或多个系统组合实现，项目中感觉不到模型的存在，我们的项目更依赖人员经验将业务需求转化为代码实现。我这个土豹子搬着小板凳来学习下(ﾉಥ益ಥ)