2019-11-25新哥，把代码放到git上给兄弟们个地址吧作者回复: 我需要时间整理一下哈，等好了再共享。
3 12
2019-11-25老师，代码有github链接吗作者回复: 本来没准备放代码的哈，我后面花时间整理一下吧。
2 5
2019-12-01我觉得老师可以讲一下CQRS，毕竟微服务好多都是要查询的哈哈作者回复: CQRS其实就是读写分离，主要解决DDD的复杂查询问题。一般是写库和读库分离，但是实效性不容易保证。其实你也可以在同一个库，用领域或者应用查询服务来完成复杂查询的。
2
2019-12-10有没有一个基于 DDD 设计实现的实际可用的开源项目可以分享下作者回复: 正在准备，好了会通知大家的。
1- 2019-11-26推广活动为一个聚合，直播推广为一个聚合，但是这两个聚合之间又是有联系的，比如直播推广可以参与推广活动。那这样这个命令到底属于哪个聚合呢？还是说将推广活动作为一个值对象呢
作者回复: 聚合内有实体吧，看看这些实体跟那个聚合根关联紧密，生命周期归聚合根管理，就放在跟聚合根在一起的聚合内，如果别的聚合要用，有两种方案，第一种是通过聚合根引用实体。第二种方案，在另外的聚合内将这个实体设计为值对象或者实体，值对象或实体的数据来源于另外的那个聚合的实体。
1 
2020-01-16老师，在请假聚合中，请假单是聚合根。那关于所有聚合实体的访问与修改是不是都要通过请假单实体走？
比如文中说的查询审批规则和修改请假流程信息，需要都通过聚合根来做吗作者回复: 新增和修改，以及针对聚合根的简单查询，都是通过聚合根来整体操作的。
对于复杂查询，可以不走领域层，按照传统模式操作就可以了。
2020-01-08老是，问下您图中列的命令和业务流的区别是什么了？作者回复: 业务流是流程阶段，命令是在这个流程阶段的某个流程的一些操作，操作包括前后端或应用之间的动作。
- 2020-01-03请问老师，我的应用需要 提供 批量导入用户的功能，那这个功能，是应该应用层承担，还是领域层承担呢？
作者回复: 是从文件系统导入吗？你可以在应用服务中打开文件，调领域层的服务来实现。
2019-12-30问下我们想做个专门对接三方的平台，让各个业务方只用关注自己的业务开发，不用陷入频繁的沟通交流中。而且对三方的压测可以只关注adapter ，这个怎么设计比较好作者回复: 可以通过BFF的模式，各业务平台完成自己的细粒度功能开发，由BFF微服务完成各业务功能组合和编排，对外提供粗粒度的接口服务。这样第三方就不需要了解太细的业务编排和实现细节了。测试也只需要对粗粒度的接口测试了。
2019-12-30命令和事件那块感觉有些模糊，比如下单是命令还是事件呢？ 按照我们的系统设计，下单则是事件。作者回复: 下单是命令，订单已下单是事件。
2019-12-24产品愿景可以不安上面的来吗？ 我的理解就是
1、产品是为谁服务
2、解决了什么问题
3、给产品确定名称
4、给产品定义功能
5、竞品分析
6、本产品的优势展开作者回复: 可以的啊，这只是一种手段。只要你们统一团队语言和目标，找到产品的核心价值点，多种方法都可以。
2019-12-22Person.createPersonInfo createPersonInfo可以算作Person实体的行为吗？什么样的方法可以直接定义在领域实体上面呢？作者回复: 实体自身的业务行为就可以作为实体的方法。DDD的领域模型更能体现面向对象的设计。涉及到多个实体的业务行为用领域服务。
- 2019-12-20请假人 其实是从人员组织关系中获取的，如果是值对象，那如果人员组织关系发生变动，或者这人改名了，如何保证一致性？
作者回复: 需要整体替换，值对象会保证发生业务那一刻的数据与源端数据一致，如果源端数据变化了，数据要一致，需要整体替换。
2019-12-15问一下老师，关于ddd读写那块，我最近看到有的文章说在ddd化为微服务中最好做到读写分离，将读的逻辑放在service（domain层的），写和其他的逻辑放在entity中，但这里会遇到spring di问题，entity不方便做di，我看的两种方法一种是通过entity的工厂类来实现实体的di，另一种是同一用repository工程类来注入。是否还有更好的方法，还有这种读写是否适合ddd（因为我自己适着用充血模型来写也发现很多时候复杂的读逻辑不适合放在entity中实现）作者回复: 复杂的查询建议独立出来，通过CQRS来实现，可以根据时效性要求设计为读写同一个库或者读写库分离的方式，复杂的查询逻辑可以独立为应用或者领域服务。复杂聚合的实体初始化建议用工厂类服务，简单的直接用构造函数就可以了。
2019-12-15老师，请假单在请假聚合里，审批人在人员组织关系聚合里，在请假单聚合根（leave.java?)是如何通过人员组织关系聚合根(Person.java)关联引用到审批人的信息的？是leava对象里有Person对象吗，然后通过Person对象导航到审批人信息？作者回复: 是的。请假聚合根会关联人员聚合的人，然后导航到审批人。
- 2019-12-15"DO 是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑。通过 DO 和 PO 转换，我们可以完成数据持久化和初始化。"“第二步：提交审批facde实现DTO转DO”一直不理解不了DO对象，老师，你可以结合这章的内容，代码说明下DO对象吗？这个DO对象应该放在项目结构哪个目录下？
作者回复: 这个DO对象是领域模型的实体对象，放在Entity目录下。DTO转DO是将外部请求数据转换为领域模型的实体对象。
2019-12-10老师，你好。对比MVC结构，controller在DDD分层架构中分到哪一层？在课程的代码目录节奏中没有看到呢？是不需要了吗？如果需要代码目录要如何设计？作者回复: 在DDD里面没有提到controller这个概念。按照分层理论，它承担应用服务与前端应用适配的工作，感觉应该是属于基础层或者用户接口层。
2019-12-02审批规则值对象有查询审批规则方法？这里不是很明白。
不应该通过领域服务或者聚合根来做查询吗？这里的值对象是充血模型？
望老师回复。作者回复: 审批规则有两个，一个是审批规则的配置数据，独立存在。另一个是保存在请假单上的审批规则，它根据请假基本信息匹配审批规则配置数据后获得，只要请假基础数据不变，你就不需要在每次提交审批的时候去查询审批规则的配置数据。依附于请假单的这个审批规则是值对象。
2019-11-28老师可否以电商系统为例，讲解一下是怎么拆分的作者回复: 不好意思哈，电商的内部流程我不是太熟悉哦。
不过不管什么样的业务，你最终目的就是为了找出命令、实体等领域对象，然后构建聚合和限界上下文。
你可以通过场景分析，模拟一个人在系统中的旅程，去分步骤操作就可以了。
2019-11-27老师好，请问场景分析是不是按角色来分，每一个场景不涉及多个角色？例如请假场景只是罗列了请假人从创建到提交审批的动作。我们一般讲请假流程的话、提交审批之后会根据审批结果进行下一步动作，比如审批者审批拒绝，那么请假者修改请假单再次提交审批，这种情况对于请假人是不是要加一个场景。我的疑问就是，老师说的场景和一般的流程有什么区别？我的理解是流程会涉及多个角色的动作，场景只是一个角色的动作。请多多指教作者回复: 可以多场景多角色，主要目的是找出所有的命令和实体对象。只要能达到这个目的，可以采用多种方法。