期末测试 | 有关DDD的内容，你掌握了多少呢？
期末测试 | 有关DDD的内容，你掌握了多少呢？
生成海报并分享赞 16
提建议
精选留言(20)
colin_fu2020-09-15欧老师好 很高兴从您的课上学到很多东西，我目前所做的项目采用了ddd的设计思想去实现，但是现在有个问题，我的po和entity还有dto中有大量的字段是重复的，然后过不去代码的重复率规定，但是以我的理解entity在ddd里面就是与之对应的po的超集 dto就是entity属性的集合或多个entity汇总，我不知道这样的理解是不是准确，想请老师解惑。作者回复: 是的，你的理解没有问题。定义这么多对象的目的就是为了实现各层的解耦，通过对象转换，保证领域模型逻辑不会受前端或者资源层逻辑的影响。设计的时候要尽量避免对象转换带来的性能损失。
共 2 条评论3![](data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg" width="72" height="72"><rect fill-opacity="0"/></svg>)
Hans2020-08-01学完了，考试100分，但是业务分析感觉比较生疏，需要多加练习实践。作者回复: 非常不错。建议多看几遍，真正理解设计思想和设计流程后，再去落地。
2
gen_jin2020-06-08学完了，考试90分，但还是不会事件风暴，具体怎么操作呢？作者回复: 你可以参考第18节的实例，找几个项目团队的小伙伴，找一个小的业务领域，从场景分析开始，提取领域对象，找到聚合根，构建聚合，然后划分限界上下文，完成微服务拆分和设计。然后参考加餐代码示例，设计微服务的分层架构代码目录，完成微服务详细设计和开发。 大致流程就是这样的。事件风暴的过程你可能比较陌生，多看几遍，理解一下它每一步的主要目标是什么？对你领域建模时有帮助的。
1
清涧飞鸟2020-05-2280分，学得不精，期待老师再出一些相关的课程！作者回复: 祝贺，已经很不错了哈。建议多看几遍，加深理解。
1
肥猫不开心2022-10-06 来自四川虽然我是满分，但是我感觉我还是不会。。
小八哥2022-02-20这个周末，两天多，很快就浏览完了。还需要参照样例花大量时间来实践。
Leric2021-10-30有一道题目是关于如何实现依赖反转的模式，repository不能代表所有外部依赖吧，感觉应该是六边形架构里的适配器模式吧
若若2021-08-25感谢欧老师的分享，非常的专业，讲解非常清晰。我也是在做保险软件这块，正如您所说保险领域非常复杂，在实施这块的时候我也是深有同感。有个问题向您咨询一下 比如我们在分析保险理赔的定核损模块，定损需要从其他厂商（如精友等）导入配件数据，导到保险公司以后又可以根据实际情况对配件的价格进行修改。我们分析将定损单作为一个聚合，那定损配件整体（若干车辆损失换件组成）肯定是跟定损有关的领域对象。现在对这个领域对象是定义成实体，还是值对象这块傻傻分不清，内部也是有些争议。争议点在于，如果定义成值对象，这里导入数据后涉及修改配件数据，而不是做整体替换（系统内也没有针对配件管理相关的功能，都是现导现用）；假如定义实体吧，又觉得实体缺少一些行为，只是一些数据。如果这块我描述的清楚的话，还请有时间帮忙指导一下。非常感谢！展开- Simple2021-07-02对子域和限界上下文得理解： 1.根据欧老师得回答，子域属于粗划分，子域一开始可能按照业务流程或者功能模块粗分，如果采用事件风暴以后确定了限界上下文边界，会不会存在之前得模块划分不合理。也就是开始粗分和战术设计推导最终推导出来得不一致。 2.也有相关书籍提到子域和限界上下文是不同视角或者维度得产物，不用强拉他们进行比较，就好比问一个主任医生和一个高级工程师哪个厉害一样，没有对比性，也不用强拉着去比较，不知道这种说法是否成立。 请知道得老师或朋友阐述下自己得观点。展开
- Simple2021-07-01https://time.geekbang.org/quiz/score?sheet_id=270337&source=1220004
- Simple2021-07-0195分，谢谢欧老师
大维2020-12-07欧老师，在实际物理部署时， 子域是作为物理单元部署吗？ 如子域A的S1访问子域B的S2服务，是通过 S1-->S2 还是 S1-->子域B网关-->S2呢？作者回复: 子域还是偏业务概念的，这个还在DDD的战略设计阶段。 我们在子域内开展事件风暴，划分出限界上下文，并根据限界上下文设计出微服务后，微服务才是物理单元的部署。当然有的子域可以划分出多个限界上下，也可能是一个限界上下，如果是一个限界上下文，那它就是部署单元。 不同微服务之间的服务访问现在一般都是通过API网关来实现。
- Hans2020-08-01https://time.geekbang.org/quiz/?act_id=137&exam_id=295&source=1220004
作者回复: 厉害！
- Hans2020-08-01老师学完你的课程，我存在如下疑问： 1. dto转化为do时，do是采用聚合根，还是可以是实体、值对象以及其他的对象吗？ 2. 如果在应用服务层存在聚合交互时，如果聚合根内部的数据满足其他聚合的要求，难道为了解耦，其他聚合还从仓储层重新获取一遍数据吗？ 3. 聚合的领域返回的响应对象, 可以是实体、值对象或聚合根吗，如果存在聚合根，必须是聚合根吗？ 4. 值对象可以理解为数据表中没有专属uuid的实体的附加信息表结构吗？ 谢谢.展开
作者回复: 1、都可以的，要根据应用层和领域层在业务逻辑处理需要什么样的DO对象，需要什么对象就转换成什么类型的对象。 2、在应用层进行跨聚合操作时，如果需要获取其它聚合的对象的数据，需要通过聚合根ID来访问其他聚合，这是其它聚合的聚合根会找到对应对象，然后返回数据，当然这个数据的初始化是通过其它聚合的仓储来完成的。 3、这个聚合是其它聚合吗？其它聚合不一定返回聚合根，返回实体和值对象也是可以的，根据你需要的数据来定，也可以临时定义一个对象。 4、值对象更多的体现领域模型的概念，它更强调描述和值的属性，在数据模型中一般不建议设计成独立的数据表，除非有基于值对象的查询要求。
hk2020-06-30老师你好，问下你们在用DDD构建微服务的同时，在具体战术实施过程中，有没有用到其他的辅助技术，比如工作流、状态机等作者回复: DDD战术设计主要设计领域对象，做好聚合和服务分层等方面的设计，目前还没有用到您说的这些辅助技术。
共 2 条评论- ...2020-05-28还有个问题请教下，最近在项目实践中试了试，遇到一些问题，如果是websocket一类的项目，其实各层都需要拿到websocket客户端对象与客户端通讯，为了实现洋葱模型那种从外到内的依赖关系，把websocket客户端包装成接口解决了这个问题；但如果是同步的http请求，内层返回的复杂数据结构，应该还是把数据模型定义在内层吧？(比如domain返回给application层的)这样才能依旧是从外到内的依赖关系？
作者回复: 你说的数据模型是不是指PO？PO与基础层的数据库结构是一一对应的。同时还有领域层DO的领域模型，DO和PO会有映射关系。一般我们暴露给前端的是DTO对象，它是由多个DO组合而成的。
共 2 条评论 - ...2020-05-28老师，遇到点疑惑，像是带有数据库事物的复杂逻辑，应该怎么设计比较好呢？这个事物对象要在application层管理生命周期么？那如果domain层的entity需要根据事物的成功与否决定是否更新，怎么设计比较优雅呢？
作者回复: 同一个微服务内，跨聚合的数据库事务在应用服务中控制就好了，或者采用事件总线的模式，保证不同聚合数据的最终一致性。
共 2 条评论 
沉迷学习Zzz2020-05-25老师你好，我现在在开发DDD中遇到了一些疑惑，比如说现在有一个场景，调查问卷，和调查问题提交，我将调查问卷和调查问卷提交数据统计分别以聚合的方式拆分，现在用户填写调查问卷在提交的时候，在应用层中先需要调用问卷领域服务判断问卷是否过期，判断问卷是否过期的结果校验是写在应用层，还是下层到问卷提交的领域服务中实现。希望老师能给出解答。作者回复: 一般来说业务规则的校验都是在领域层完成的。是否过期的校验属于业务规则校验，这种校验需要聚合内实体数据进行配合，所以应该放在领域层。
高阳路人2020-05-2275分，有一题单选不小心点错了。掌握不够好，还要再学一遍。谢谢老师的精彩课程。老师什么时候出新专栏，很期待。作者回复: 也还不错呢，多看几遍，理解的会更深刻。近期在准备一本书，等好了再告诉大家哈。
Martin2020-05-22题出的很好，在课文中没有明确定义，或者我没有细看到的，在题目中解答了我部分疑惑。 比如：拆分微服务的依据我一直以为是限界上下文，但我在实践过程中发现聚合之间也是解耦的，理论上也是可以拆分成微服务的。 题目中说到：理论上一个限界上下文就可以设计为一个微服务；聚合在领域模型中是一个最小的业务逻辑单元，它也是可以拆分为微服务的最小单元。展开作者回复: 是的，但是大多是基于限界上下文，不建议对聚合过度拆分，除非非常有必要。
