作者回复: 两个问题都回答得很到位 👍🏻 隐喻实际上就是初中学修辞时学的“暗喻”或“打比方”，以便容易理解概念。比如说把多台计算机连起来，这个概念不好理解，但“网”这个词自古就有，那么说成计算机网络就好理解了。计算机连起来，和原来的渔网，蜘蛛网等本来没关系，这里是用“网”来打比方。

作者回复: 这样也是一种可行的选择。下节课还会有另一种方法，稍微牺牲一些封装性

作者回复: factory主要不是为了层间依赖，而是为了把复杂的创建逻辑抽出来。课程里也给了另一种方法：assembler.

作者回复: 也是一种可行的思路，不过这样可能导致DTO为了满足各个层面的传输要求而变得复杂，要慎重一点。最好不要让领域层依赖这个意义上的DTO。

作者回复: 会，但没这么快

作者回复: 哈哈，说得对

作者回复: 你实际上问了两个层面的问题，一个是同一个上下文中，跨聚合的领域逻辑；另一个是跨上下文的领域逻辑。 关于跨聚合的逻辑，直接在领域服务中实现就可以了。如果您觉得这样做有问题，请举一个具体的例子来谈。 关于跨上下文的领域逻辑，可以引入上下文映射和防腐层来解决。这个问题咱们在第三迭代，讲限界上下文的时候再谈。

作者回复: 1.书里写的服务和本文中的领域服务是一个东西吗？ 【答】书里的服务包含“领域服务”“应用服务”“基础设施服务”三种 2.有些操作从本质上讲是一些活动或动作，而不是事物, 故这些操作从概念上讲不属于任何对象。 那么在本文中,添加组织中,校验组织的这个操作,从本质上不应该属于组织这个领域对象吗？还是因为它牵扯到了很多领域对象, 故将其放到领域服务中了？ 【答】把这些逻辑写在领域对象里面的话，可能造成领域对象无谓的复杂，所以把逻辑剥离出来。 如果强行将这个操作要放到领域对象中的话, 是不是组织对象必须存在租户和上级组织的引用是吗？ 【答】是 3.我的理解是领域服务和工厂模式甚至是可以互相取代的,领域模式如果已经把所有的校验逻辑都做完了, 就单单进行转化, 哪怕参数过多,一个一个赋值也可以不用工厂模式把？ 那对于我的理解来说, 工厂模式创建领域对象, 业务规则复杂的时候, 我放到领域服务中,只有当结构复杂的时候,我在用工厂是不是也可行？ 【答】可行

作者回复: 1. 如果说我仅仅只有校验1-2个业务逻辑, 并且领域对象中没有这些所需的关联对象时,我也要搞一个工厂模型吗？ 是不是像上文那样直接放到领域服务就行了？ 【答】可以放在领域服务，不过如果一个领域服务的职责是创建对象的话，那么其实就是一个工厂了。 2.假设我现在有一个这样的场景, 发送短信的场景, 类比文中的添加添加组织。 它也存在需要很多校验,才能创建一个领域对象。比如说敏感词校验、黑名单的校验逻辑,模板校验逻辑等 现在一个困惑的是, 我看老师没有在领域模型图里画工厂, 而我这个图里如果不画, 其他的一些领域对象孤孤单单,没有任何关联。 https://www.processon.com/view/link/65068631464f0d50af3d6f7f 是我理解的哪里有问题吗？ 【答】1）之所以领域模型里没有画工厂，是因为工厂不是业务概念，也就是说，业务专家不会和我们谈“工厂”这个概念。2）孤孤单单本身不是问题，只要正确反映了业务概念 3）如果建模再深入一点，可以见一个“校验规则”实体，它有很多子类，比如“敏感词校验”“黑名单校验”等，然后这些字类就可以和那几个“孤单”的对象有“依赖”关系了。 3.如果我这个发送短信的场景,不仅存在一些逻辑校验,还要调用基础设施层完成真正的发送后,才能Build这个领域对象, 这种情况, 还能用工厂模式吗？ 是这样的逻辑吗---领域层调基础设施层后,在继续领域层没有处理完毕的操作？ 【答】我倾向于这样做：用一个App Service 中的方法（“发短信”方法），在这个方法里先做调用基础设施等工作，然后再调用工厂创建对象（如果需要的话），最后保存对象。