14 | 代码模型（下）：如何保证领域模型与代码模型的一致性？
领域对象的整理
请订阅文章所属专栏。
精选留言(29)
ANYI1，对于实体采用充血模型，包含自己的属性及行为，例如保持、更新、删除等行为方法，需要持久化，依赖基础层数据库操作，是在实体直接引入，例如mybatis的mapper？
2，对于相对简单的实体操作增删改查这种，需要暴露到接口层；那要一层一层向上封装，实体》领域服务》应用服务》接口服务；这样是不是又显得代码很多余；一个简单的增加修改方法接口，需要很多冗余代码，上层也没有其他逻辑，封装一下调用下层，写一个接口，要写很多层次调用，是否会很臃肿啰嗦，是不是就可以直接接口层封装就省去一些层呢？
3，在服务编排上有没有一些框架什么的？还是都是通过if else的手写？作者回复: 1、实体的这些数据库映射是通过mapper来实现的。
2、松散分层架构是可以跨层调用了，实现起来很容易。但是在复杂的情况下，服务不太容易管理，比如，你可能不知道你的方法到底被谁组合和封装了，一旦出现方法变更，你不容易一次找出所有受影响方。而逐层封装的话，你只需要逐层通知到上层就可以了。
3、微服务内的服务编排相对简单，就是业务逻辑的执行顺序而已，个人感觉不需要引入什么工具。2019-11-15 5 2
何沛abcAppService{
abDomainService();
c.f();//老师这里是不是应该调整为cDomainService();
}作者回复: 谢谢指出，图已调整。
2019-11-15 1
张迪领域实体的方法必须要通过领域服务封装一下吗？作者回复: 如果直接对外暴露的话，建议封装一下。避免业务逻辑泄露。
2019-11-15 1
盲僧作者代码的地址可以发一下吗，或者给个demo作者回复: 等我有时间的时候，我整理一个吧。
2019-11-15 1
鸭子领域服务过多会不会导致领域中的实体对象对象变成贫血模型，如果没有领域服务又很可能把领域内的逻辑放到应用服务用去，纠结。作者回复: 实体对象的方法在实体类内实现，有些领域服务只是做封装或者组合编排。
领域逻辑别放到应用服务中去，容易让领域模型逻辑与编排逻辑出现混乱，最后做成三层架构了。2019-11-15 1
@倾杯老师，代码模型这块我还有一点不太确定，就是dto->do这个转换方法具体是在controller中调用还是在xxAppService中调用呢？反过来do->dto方法又该是在哪个类里调用呢？作者回复: 你可以在用户接口层创建DTO类和assembler类。在assembler类里完成映射。
2019-12-09- 鱼养猫服务A调用服务B,是放在基础设施层吗?
作者回复: 你说的是微服务之间的服务调用，还是微服务内的应用服务或领域服务？微服务之间服务调用可以通过API网关来调用，API网关是基础层的组件。微服务内的服务调用，直接服务跨层调用就可以了。
2019-12-06 - 鱼养猫数据的持久化是在领域服务中还是实体中?如果持久化放在实体中,使用spring和mybatis就得把实体声明@Component 注入mapper,还得设置多例.持久化是否可以放在领域服务中去做?
作者回复: 持久化是通过仓储来做。这样通过依赖倒置，可以解耦领域模型实现与数据库资源。
2019-12-06 - Geek_4660f31、领域服务和聚合根是什么关系
2、领域服务是封装了多个实体的业务，那么领域服务是存放在聚合根内的么
3、应用服务是直接调用领域服务还是调用聚合根作者回复: 聚合根由于管理了聚合内所有的实体和值对象，它的有些方法其实可以替代部分领域服务的功能。但是我建议聚合根本身的业务行为放在聚合根的方法内，聚合内的所有领域服务用一个单独的领域服务类来实现。
应用服务应该调用领域服务。2019-12-01 
Jesen老师，如果把仓储Respository的实现放到基础设施层，其仓储接口定义在领域层里面，那么在领域层里面该怎么持久化呢，可以通过在应用层中将仓储注入到领域服务里面来实现吗？作者回复: 这个只是代码存放目录的考虑。具体的持久化是在仓储实现的服务里面。为了方便聚合的重新组合，我在代码目录结构里面将仓储的接口和实现都放在领域层的聚合目录下，如果微服务架构演进，你可以直接将聚合相关的代码一起拿走。
2019-11-29- Marshall“如果一个业务动作或行为跨多个实体，我们就需要设计领域服务”这句怎么理解？
这多个实体是聚合内的，还是说跨聚合的？如果是聚合内的，不是由聚合中的行为来处理吗？如果是跨聚合的，但是实体是通过聚合根访问的，是不是这句话要改为“如果一个业务动作或行为跨多个聚合，就需要设计成领域服务”作者回复: 不是。
实体完成自己的业务行为，但是聚合内有一些业务逻辑是由多个实体共同完成的。这种业务行为是跨了多个实体。比如支付订单的操作，需要对订单以及订单明细两个实体进行操作，这个行为就是一个领域服务。2019-11-28 
zjCreatePersonInfo这个方法，如果传入的参数太多怎么办，代码会不会不太优雅作者回复: 参数大部分都是实体对象。
2019-11-22 3- zj生成客户编码这个有个问题，如果是要用到中间件生成客户编码，那这个聚合根Person不就依赖了基础层的中间件了吗
作者回复: 你这通过生成客户编码的领域服务，调用中间件的服务就可以吧。或者在领域服务内按照业务规则自己生成编码也可以吧。
2019-11-22 2 - Geek_1c00cb前面一直在讲仓储层的依赖反转，代码实现时怎么又放到领域里面了，是领域里面控制如何选择仓储，而不是应用层？
作者回复: 这是为了聚合之间代码重组的方便，一次可以将聚合代码和仓储代码迁移走。上一节讲聚合的代码目录的时候有特别说明的。
2019-11-19 1 
杨杰关于接口层、应用层、领域层在相互调用的时候应该采用什么形式传输呢？比如说接口层接收的参数肯定是DTO对象，那么DTO是否可以传入到下面的应用层甚至领域层呢？还是应用层和领域层都需要定义自己的传输对象？作者回复: 有dto，do，po等对象，不同的层采用不同的对象。第16节会有专门介绍。
2019-11-19 1- 杨杰在实际操作的时候经常会碰到一个问题，加入一个领域服务内部需要创建两个聚合（或实体）完成业务操作，有几个细节的问题：
1、在创建这个实体的问题，是在领域服务里面把这个两个实体的大部分属性直接赋值，还是应该有工厂方法来创建实体？
2、关于实体封装核心业务逻辑，在这个例子里面怎么才能算核心业务逻辑呢？比如说通过单件*数量来计算金额？作者回复: 1.通过聚合根调仓储来做数据初始化。复杂的用工厂，不复杂的没必要用工厂。
2计算的业务逻辑一般都是核心逻辑。2019-11-18 2 
阿玛铭项目正好做到这一步，记录一下：
应用服务对领域服务的编排和封装技巧。
关注应用服务的简洁性和实用性。服务api的编排有大而全、实用而精简（来自用户界面、定时任务、领域事件等触发源头的需求）两种。如果希望较低的层次更加稳定，就需要基础层（非四层模型内容）微服务提供大而全的api集合，再由较高层的微服务根据触发源的需求做编排。这里涉及业务操作数据的一致性和高层微服务的灵活性之间的权衡。大而全需要更多地引入事件总线（MQ）或者分布式事务中间件，实用而简洁会导致前台灵活性不足，进而影响平台级别的复用能力。2019-11-17
陈云领域类，有领域异常吧？比如我有一个背包聚合，扣减背包库存的时候，可能抛出库存不够的异常，这种异常也是要定义在领域层吧？作者回复: 是的。
2019-11-17
Todd BD如果我有两个微服务， 查询场景下， 服务A需要调用服务B去获取服务B中聚合的一个值对象（Z.class）， 对于在服务A中，从服务B里拿来的这个值对象也同样是当值对象使用并绑定在服务A的一个聚合对应的DTO里， 请问服务A是否能直接使用服务B包中的Z.class，还是说需要在A服务中重新创建一个相应的Class以起到防腐层的效果？作者回复: 都两个微服务了，在两个不同的项目里，要重建一个新的值对象的class的。
2019-11-16 3- Geek_2973a9除了聚合根管理功能外，我们还可以用 DDD 的其它设计方法——请问还有哪些方法？
作者回复: 分层啦，依赖关系，领域划分，事件风暴等等，太多了。
2019-11-16