情况如下:根据无处不在的语言,可以将支付发送到支付网关(通过ACL (防腐败层)+OHS/PL集成在不同的有界上下文中)。
在本地环境中,支付是聚合根,所以我期望这样的设计:
payment.send();但这里的问题是,支付需要知道如何通过ACL到OHS将其状态发送到其他有界上下文。因此,我需要将这个PaymentGatewayService/Adapter作为参数:
payment.send(paymentGatewayService);在这种情况下,paymentGatewayService返回一些值对象,这些值对象可以在send()方法中通过支付进行处理。但我听说,通过方法参数或DI将服务注入聚合根目录并不是很好的实践,但也许可以吗?这里的好处是我没有将聚合结构暴露给外部。或者我应该创建一些域服务来覆盖它,比如:
Payment payment = ...
payment = paymentGatewayService.send(payment);
paymentRepository.store(payment);在这种情况下,我真的不喜欢这个反转,因为我必须直接公开聚合结构,这样网关服务才能转换成它的模型。此外,这也是导致贫血在支付总额。
我怎样才能妥善处理这些情况?
发布于 2017-09-29 13:27:03
但我听说,通过方法参数或DI将服务注入聚合根目录并不是很好的实践,但也许可以吗?
这是有代价的。
Evans将域服务描述为服务于此角色的构造。所以我们把一个用域语言表达网关概念的适配器传递给聚合器,这样模型就可以与它交互。域服务的底层实现可能将实际工作委托给应用程序服务或基础设施服务。
因此,正确的做法,是完全一致的领域重点的方法。
但是它在副作用和你可能不想要的聚合之间引入了一些耦合。
让我们更仔细地看一下第一个例子的封面
payment.send(paymentGatewayService);并试图明确地分解正在发生的事情。
Payment::send(paymentGatewayService):
x = this.getCurrentState()
m = createPaymentMessage(x)
y = paymentGatewayService.send(m)
z = calculateNewState(x, y, m)
this.setState(z)也就是说,我们这里有三个步骤
我们需要的是:我们是否希望在总体上、应用程序中产生这些副作用,或者可能将这些副作用隐藏在一个负责协调的不同领域服务中?
PaymentProtocol::send(payment, paymentGateway):
m = payment.createPaymentMessage()
y = paymentGatewayService.send(m)
payment.onPaymentSent(y)在本设计中,支付协议安排了对支付和支付网关的副作用。这为您提供了一个干净的聚合(其职责是维护它自己的不变),并将所有的流程保持在一个位置上。
在这种情况下,我真的不喜欢这个反转,因为我必须直接公开聚合结构,这样网关服务才能转换成它的模型。此外,这也是导致贫血在支付总额。
这是不完全正确的--聚合仍然完全负责维护自己的不变;它只是免除了管理它感兴趣的副作用的责任。聚合从不公开它自己的结构,它只公开它使用自己的结构创建的消息。
当然,不喜欢还是可以的。
https://softwareengineering.stackexchange.com/questions/358301
复制相似问题