13｜迭代二概述：怎样更深刻地理解领域知识？

【代码更新】 同学们好，我是编辑小新。 迭代一配套代码已整理到GitHub，希望同学们好好利用，觉得不错别忘了给老师点个Star。 代码链接：https://github.com/zhongjinggz/geekdemo

🚩【特别策划之建模题目挑战赛】 同学们好，我是这门课的编辑小新，为了帮助同学们更好的学习和理解DDD，更深入地和老师学习、互动。我们给大家安排了这次建模题目，体现大家综合实力的时候到了！ 钟老师给出了如下需求场景，请你来绘制领域模型。 假设你所在的公司想实施敏捷软件开发，委托你为公司开发一个敏捷项目管理软件。公司领导提出的需求是这样的： 1.公司会开发很多款软件产品，每个产品有一个产品待办清单（product backlog）。 2.产品待办清单中的待办项是用户故事，由产品经理提供。 3.用户故事有一个文字性的描述，还有若干验收条件（Acceptance Criteria）。 4.产品经理可调整代办项的优先级。 5.每个用户故事要估算故事点。 6.每个迭代，项目经理把用户故事移入迭代待办清单（sprint backlog）。 7.每个迭代，由一个敏捷团队负责。 8.迭代待办清单所有故事点的和不能超过迭代容量。 9.每个用户故事由一个同事负责。 10.每个用户故事有TODO、DOING、DONE 三种状态，由开发人员切换状态。 请根据上面的场景，用你熟悉的工具绘制出系统的领域模型。然后把模型以图片的形式导出，贴在你喜欢的共享文档（例如腾讯文档、石墨文档等），然后在这节课的留言区里提交超链接就可以了，提交格式为昵称+链接。我看到后，会精选评论并置顶。 这道题假设你学习完了迭代一，并且了解敏捷软件开发过程。如果对“产品代办清单”“迭代代办清单”“用户故事”“验收条件”“故事点”“敏捷团队”等概念还不了解的话，可以去网上搜一下，这些都是敏捷的一些基本概念。 请注意这道题的目的不是为了考试，而是锻炼同学们的建模技能，所以你也不妨发挥一下，增加一些合理的需求，以便使模型更加丰富。期待你的“作业”！

概念图 concept map 是 1970 年左右提出来的，不知道是什么原因，没有思维导图那么流行，但是表达能力还是挺好的。没有看过《领域驱动设计》，所以专栏中的几张概念图让我印象深刻，感觉在头脑风暴的时候可以使用。 对于思考题，聚合和值对象之前都曾经听说过，而且一般不作为特别重点的概念讲解，所以对于迭代二有点好奇。 1. 我的理解，聚合就是把一组相关的领域模型集合起来，提炼出聚合根，比如人员管理上，员工就可以作为一个聚合根。 2. 值对象一般是不需要实例化的对象，也就是不能独立存在的对象，比如人员的角色、岗位、职级之类的。

看了迭代二的需求，故事越来越真实了

1. 你以前是否听说过聚合，你是怎么理解的？ 聚合也是目前微服务划分的一种常用手段，将业务关系紧密，规模大小合适的一些领域对象作为一个聚合放在一个微服务中。 2. 你以前是否听说过值对象，你是怎么理解的？ 值对象，判断唯一性可以根据其值判断，而不是根据id判断，在DDD中一般根据是否有单独的持久化记录来判断。

其实一直想知道： 1.为什么领域对象只有实体和值对象两种？他们是否就是0和1的关系，在这个维度就这两个？ 2.领域服务、领域事件又是什么维度的对象？ 3.设计模式中的角色对象和领域对象是怎样的关系？

刚好想问如何对照《DDD》

老师深入浅出，以前做的项目用到了DDD，对于项目的架构设计一直理解的不到位。看了老师的课，受益匪浅。

模型的实现 一节中的图是否有问题？ 适配器层， 应该是被动适配器包含仓库的实现。 图中画错了。

https://www.processon.com/view/link/64896e101da920111bce9e8f 员工角色，通过starUml不太好画，有没有好的工具推荐