11｜代码实现（中）：怎样创建领域对象、实现领域逻辑？
讲述：钟敬
时长:大小14.52M
“表意接口”（Intention-Revealing Interfaces）模式
精选留言
赵晏龙2023-01-02 来自广东1你问我值不值？我当然说值！代码即文档 2表意接口的接口只是个概念，不是编程语言中的interface。作者回复: 全中👍🏻
18
Michael2022-12-29 来自广东问题1.值得 从代码维护的角度说，抽方法可以用方法名来表意 从代码设计上说，方法也是一种抽象，应该依赖抽象而不是实现 问题2.这里的接口指的是抽象，不是编程语言里的语言特性，应该跟语言无关 关于隐喻，想请教老师，到底什么是隐喻呢？看徐老师的业务建模，他也提到为系统找到一个简洁的隐喻来解决问题之类的，不是很懂，老师可否再解释解释作者回复: 两个问题都回答得很到位 👍🏻 隐喻实际上就是初中学修辞时学的“暗喻”或“打比方”，以便容易理解概念。比如说把多台计算机连起来，这个概念不好理解，但“网”这个词自古就有，那么说成计算机网络就好理解了。计算机连起来，和原来的渔网，蜘蛛网等本来没关系，这里是用“网”来打比方。
8- 虚竹2022-12-29 来自广东builder模式用起来还是过于繁琐，因为实际业务参数可能很多，我们更可能选择将DTO对象定义下沉，通过内层包或者类名后缀知道它是用于应用层的
作者回复: 这样也是一种可行的选择。下节课还会有另一种方法，稍微牺牲一些封装性
共 3 条评论4 
瀚海2023-07-19 来自上海感觉为了DTO类不破坏层间依赖关系，而引入builder、factory实在过于重了作者回复: factory主要不是为了层间依赖，而是为了把复杂的创建逻辑抽出来。课程里也给了另一种方法：assembler.
3
Ice2023-02-03 来自四川DTO是否可以放到common中作为支撑层被各层引用？作者回复: 也是一种可行的思路，不过这样可能导致DTO为了满足各个层面的传输要求而变得复杂，要慎重一点。最好不要让领域层依赖这个意义上的DTO。
2
Tree2022-12-29 来自广东老师，课程中涉及到的代码，会开源出来放在github上吗？作者回复: 会，但没这么快
共 3 条评论2
6点无痛早起学习的和...2023-01-16 来自北京一些问题： 3. 这里的校验规则是否又分的太多类了，是否直接用一个类里封装校验规则即可 4. 为什么不把校验规则放到相应的 Dto 实体类里去，而去单独去抽离一个“领域服务”模式 5. 用复杂的 Builder 模式去创建领域对象，有点太复杂了，实际项目中，应该不会采用这种方式，为了完全依赖关系去牺牲代码编码性，这个实际上需要权衡。作者回复: 3.原则是一个类不要太大，要关注点分离，至于怎么分，可以斟酌，你可以看看有没有其他方案 4.首先，DTO和实体不一样，DTO只传数据，不应该有业务规则。至于是否放在实体，原则是优先考虑放在实体，不行的话再放领域服务。之所以我们现在放在领域服务，是因为我们约定了实体不访问数据库，而这些逻辑要访问数据库。如果约定实体也可以访问数据库，那么有些逻辑放在实体也可以 5.是的，要权衡。
1
老狗2023-01-10 来自广东最可怕的是有注释但是注释说的跟代码不是一回事作者回复: 哈哈，说得对
1
张逃逃2023-01-08 来自广东有个疑问请教老师，为什么不把Validator的逻辑封装到Repository？作者回复: 作为适配器的Repository应该单纯一点，就是数据访问，其他什么都不做。
1
曦2022-12-30 来自广东过去，单纯的以为领域服务就是XxxDomainService，然后在这个类中封闭很多方法。看了老师的解释，恍然大悟。但是，在实践的过程中，有一些业务规则，是需要通过不同的上下文或者聚合交互验证实现的，所以这些规则很难抽象到独立的、具体的某一个领域服务中，于是，一些原本属于领域层的知识在应用层进行了组合，这使得应用层又特别的臃肿且破坏了分层也只能边界，这种情况，老师要如何解决？或者类似的解决方案？作者回复: 你实际上问了两个层面的问题，一个是同一个上下文中，跨聚合的领域逻辑；另一个是跨上下文的领域逻辑。 关于跨聚合的逻辑，直接在领域服务中实现就可以了。如果您觉得这样做有问题，请举一个具体的例子来谈。 关于跨上下文的领域逻辑，可以引入上下文映射和防腐层来解决。这个问题咱们在第三迭代，讲限界上下文的时候再谈。
共 3 条评论1