作者回复: 1、实体的这些数据库映射是通过mapper来实现的。
2、松散分层架构是可以跨层调用了,实现起来很容易。但是在复杂的情况下,服务不太容易管理,比如,你可能不知道你的方法到底被谁组合和封装了,一旦出现方法变更,你不容易一次找出所有受影响方。而逐层封装的话,你只需要逐层通知到上层就可以了。
3、微服务内的服务编排相对简单,就是业务逻辑的执行顺序而已,个人感觉不需要引入什么工具。
作者回复: 谢谢指出,图已调整。
作者回复: 如果直接对外暴露的话,建议封装一下。避免业务逻辑泄露。
作者回复: 等我有时间的时候,我整理一个吧。
作者回复: 实体对象的方法在实体类内实现,有些领域服务只是做封装或者组合编排。
领域逻辑别放到应用服务中去,容易让领域模型逻辑与编排逻辑出现混乱,最后做成三层架构了。
作者回复: 你可以在用户接口层创建DTO类和assembler类。在assembler类里完成映射。
作者回复: 你说的是微服务之间的服务调用,还是微服务内的应用服务或领域服务?微服务之间服务调用可以通过API网关来调用,API网关是基础层的组件。微服务内的服务调用,直接服务跨层调用就可以了。
作者回复: 持久化是通过仓储来做。这样通过依赖倒置,可以解耦领域模型实现与数据库资源。
作者回复: 聚合根由于管理了聚合内所有的实体和值对象,它的有些方法其实可以替代部分领域服务的功能。但是我建议聚合根本身的业务行为放在聚合根的方法内,聚合内的所有领域服务用一个单独的领域服务类来实现。
应用服务应该调用领域服务。
作者回复: 这个只是代码存放目录的考虑。具体的持久化是在仓储实现的服务里面。为了方便聚合的重新组合,我在代码目录结构里面将仓储的接口和实现都放在领域层的聚合目录下,如果微服务架构演进,你可以直接将聚合相关的代码一起拿走。
作者回复: 不是。
实体完成自己的业务行为,但是聚合内有一些业务逻辑是由多个实体共同完成的。这种业务行为是跨了多个实体。比如支付订单的操作,需要对订单以及订单明细两个实体进行操作,这个行为就是一个领域服务。
作者回复: 参数大部分都是实体对象。
作者回复: 你这通过生成客户编码的领域服务,调用中间件的服务就可以吧。或者在领域服务内按照业务规则自己生成编码也可以吧。
作者回复: 这是为了聚合之间代码重组的方便,一次可以将聚合代码和仓储代码迁移走。上一节讲聚合的代码目录的时候有特别说明的。
作者回复: 有dto,do,po等对象,不同的层采用不同的对象。第16节会有专门介绍。
作者回复: 1.通过聚合根调仓储来做数据初始化。复杂的用工厂,不复杂的没必要用工厂。
2计算的业务逻辑一般都是核心逻辑。
作者回复: 是的。
作者回复: 都两个微服务了,在两个不同的项目里,要重建一个新的值对象的class的。
作者回复: 分层啦,依赖关系,领域划分,事件风暴等等,太多了。