期末测试 | 有关DDD的内容，你掌握了多少呢？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
欧创新的文章《期末测试：有关DDD，你掌握了多少呢？》提供了一套期末测试题，共20道题目，满分为100分，旨在帮助读者检测对领域驱动设计（DDD）的掌握程度。这篇文章主要针对技术学习者，通过测试题目的形式，让读者快速了解自己在DDD方面的学习成果。欧创新在文章中表达了对读者认真学习的肯定，并感谢他们的支持。通过这篇文章，读者可以得知欧创新对于技术学习的重视，以及他对读者学习成果的关注。整体而言，这篇文章是一篇针对技术学习者的期末测试题目，旨在帮助他们检测对DDD的掌握程度。
《DDD 实战课》，新⼈⾸单¥59
全部留言(21)
- 最新
- 精选
colin_fu欧老师好 很高兴从您的课上学到很多东西，我目前所做的项目采用了ddd的设计思想去实现，但是现在有个问题，我的po和entity还有dto中有大量的字段是重复的，然后过不去代码的重复率规定，但是以我的理解entity在ddd里面就是与之对应的po的超集 dto就是entity属性的集合或多个entity汇总，我不知道这样的理解是不是准确，想请老师解惑。作者回复: 是的，你的理解没有问题。定义这么多对象的目的就是为了实现各层的解耦，通过对象转换，保证领域模型逻辑不会受前端或者资源层逻辑的影响。设计的时候要尽量避免对象转换带来的性能损失。
2020-09-1523
Hans学完了，考试100分，但是业务分析感觉比较生疏，需要多加练习实践。作者回复: 非常不错。建议多看几遍，真正理解设计思想和设计流程后，再去落地。
2020-08-012- gen_jin学完了，考试90分，但还是不会事件风暴，具体怎么操作呢？
作者回复: 你可以参考第18节的实例，找几个项目团队的小伙伴，找一个小的业务领域，从场景分析开始，提取领域对象，找到聚合根，构建聚合，然后划分限界上下文，完成微服务拆分和设计。然后参考加餐代码示例，设计微服务的分层架构代码目录，完成微服务详细设计和开发。 大致流程就是这样的。事件风暴的过程你可能比较陌生，多看几遍，理解一下它每一步的主要目标是什么？对你领域建模时有帮助的。
2020-06-081 
清涧飞鸟80分，学得不精，期待老师再出一些相关的课程！作者回复: 祝贺，已经很不错了哈。建议多看几遍，加深理解。
2020-05-221
大维欧老师，在实际物理部署时， 子域是作为物理单元部署吗？ 如子域A的S1访问子域B的S2服务，是通过 S1-->S2 还是 S1-->子域B网关-->S2呢？作者回复: 子域还是偏业务概念的，这个还在DDD的战略设计阶段。 我们在子域内开展事件风暴，划分出限界上下文，并根据限界上下文设计出微服务后，微服务才是物理单元的部署。当然有的子域可以划分出多个限界上下，也可能是一个限界上下，如果是一个限界上下文，那它就是部署单元。 不同微服务之间的服务访问现在一般都是通过API网关来实现。
2020-12-07- Hanshttps://time.geekbang.org/quiz/?act_id=137&exam_id=295&source=1220004
作者回复: 厉害！
2020-08-01 - Hans老师学完你的课程，我存在如下疑问： 1. dto转化为do时，do是采用聚合根，还是可以是实体、值对象以及其他的对象吗？ 2. 如果在应用服务层存在聚合交互时，如果聚合根内部的数据满足其他聚合的要求，难道为了解耦，其他聚合还从仓储层重新获取一遍数据吗？ 3. 聚合的领域返回的响应对象, 可以是实体、值对象或聚合根吗，如果存在聚合根，必须是聚合根吗？ 4. 值对象可以理解为数据表中没有专属uuid的实体的附加信息表结构吗？ 谢谢.
作者回复: 1、都可以的，要根据应用层和领域层在业务逻辑处理需要什么样的DO对象，需要什么对象就转换成什么类型的对象。 2、在应用层进行跨聚合操作时，如果需要获取其它聚合的对象的数据，需要通过聚合根ID来访问其他聚合，这是其它聚合的聚合根会找到对应对象，然后返回数据，当然这个数据的初始化是通过其它聚合的仓储来完成的。 3、这个聚合是其它聚合吗？其它聚合不一定返回聚合根，返回实体和值对象也是可以的，根据你需要的数据来定，也可以临时定义一个对象。 4、值对象更多的体现领域模型的概念，它更强调描述和值的属性，在数据模型中一般不建议设计成独立的数据表，除非有基于值对象的查询要求。
2020-08-01 
hk老师你好，问下你们在用DDD构建微服务的同时，在具体战术实施过程中，有没有用到其他的辅助技术，比如工作流、状态机等作者回复: DDD战术设计主要设计领域对象，做好聚合和服务分层等方面的设计，目前还没有用到您说的这些辅助技术。
2020-06-302
...还有个问题请教下，最近在项目实践中试了试，遇到一些问题，如果是websocket一类的项目，其实各层都需要拿到websocket客户端对象与客户端通讯，为了实现洋葱模型那种从外到内的依赖关系，把websocket客户端包装成接口解决了这个问题；但如果是同步的http请求，内层返回的复杂数据结构，应该还是把数据模型定义在内层吧？(比如domain返回给application层的)这样才能依旧是从外到内的依赖关系？作者回复: 你说的数据模型是不是指PO？PO与基础层的数据库结构是一一对应的。同时还有领域层DO的领域模型，DO和PO会有映射关系。一般我们暴露给前端的是DTO对象，它是由多个DO组合而成的。
2020-05-282- ...老师，遇到点疑惑，像是带有数据库事物的复杂逻辑，应该怎么设计比较好呢？这个事物对象要在application层管理生命周期么？那如果domain层的entity需要根据事物的成功与否决定是否更新，怎么设计比较优雅呢？
作者回复: 同一个微服务内，跨聚合的数据库事务在应用服务中控制就好了，或者采用事件总线的模式，保证不同聚合数据的最终一致性。
2020-05-282
