处理领域事件:缺失的部分
原文链接
系列文章目录
一、简单的CQRS实现与原始SQL和DDD
二、使用EF的领域模型的封装和持久化透明（PI）
三、REST API数据验证
四、领域模型验证
五、如何发布和处理领域事件
六、处理领域事件:缺失的部分
七、发件箱模式（The Outbox Pattern）
八、.NET Core中的旁路缓存模式（Cache-Aside Pattern）
前言
前段时间我写了一篇关于发布和处理域事件的文章。此外，在其中一篇文章中，我描述了发件箱模式（The Outbox Pattern），它在不使用2PC协议的情况下为我们提供了与外部组件/服务集成时至少一次的交付（At-Least-Once delivery）。
这次我想结合这两种方法来完成之前的文章。我将提出一个完整的解决方案，考虑到事务边界，使系统以结构化的方式来可靠地进行数据处理。
系统深度
首先，我想描述一下什么是浅系统（Shallow System），什么是深系统（Deep System）。
浅系统
通常情况下，在对系统做了一些操作之后，并没有发生太多事情，这时系统就被认为是浅的。
这类系统的一个典型和最流行的例子是，它有许多CRUD操作。大多数操作涉及管理显示在屏幕上的数据，下面几乎没有业务逻辑。有时这样的系统也可以称为数据库浏览器。
另一个可以指向浅系统的启发是能够通过GUI原型实际地指定这样一个系统的需求。系统的原型(可能加上了注释)向我们展示了这个系统应该如何工作，这就足够了——如果下面什么都没有发生，那么就没有什么需要定义和描述的了。
从领域驱动设计的角度来看，它通常是这样的:在聚合上执行命令（Command ）只发布了一个领域事件，然后什么都没有发生。没有此事件的订阅者，没有处理器/处理程序，没有定义工作流。没有与其他上下文或第三系统的交流。它是这样的:
执行动作，处理请求，保存数据-故事结束。通常，在这种情况下，我们甚至不需要DDD。事务脚本（Transaction Script）或活动记（Active Record）就足够了。
深系统（Deep system）
深系统(正如人们很容易猜到的那样)与浅系统完全相反。
设计一个深系统是用来解决非平凡（non-trivial）和复杂领域中的一些问题的系统。如果领域是复杂的，那么领域模型也将是复杂的。当然，领域模型应该尽可能地简化，同时它也不应该丢失给定上下文中最重要的方面(就DDD -限界上下文而言)。然而，它包含许多需要处理的业务逻辑。
我们没有通过GUI原型指定一个深系统，因为下面发生了太多事情。保存或读取数据只是我们的系统所做的操作之一。其他活动包括与其他系统的通信、复杂的数据处理或调用系统的其他部分。
这一次，在领域驱动设计实现的上下文中发生了更多的事情。聚合可以发布多个领域事件，对于每个领域事件，可以有多个处理程序负责不同的行为.此行为可以是与外部系统通信，也可以是在另一个聚合上执行命令，该聚合将再次发布其事件，而系统的另一部分将订阅该事件。这个方案会重复，我们的领域模型会以响应式的方式（reactive manner）做出反应:
问题
在帖子中，关于发布和处理域事件给出了非常简单的情况，整个解决方案不支持由另一个聚合重新发布(和处理)事件，这些事件的处理是由先前的领域事件产生的。换句话说，不支持响应式的复杂流和数据处理。只有一个命令->聚合->领域事件->处理程序场景是可能的。
最好在一个具体的例子中考虑这个问题。让我们假设客户下订单后的需求:
- 应向客户发送确认订单的电子邮件
- 应该创建新的付款
- 应发送有关新付款给客户的电子邮件
这些要求如下图所示:
让我们假设在这个特定的情况下，订单放置和支付创建都应该发生在同一个事务中。如果交易成功，我们需要发送两封关于订单和付款的邮件。让我们看看如何实现这种类型的场景。
解决方案
我们必须牢记的最重要的事情是交易的边界。为了使我们的生活更轻松，我们必须做以下假设:
- 命令处理程序定义事务边界。当调用命令处理程序并在结束时提交时，事务将启动。
- 在相同事务边界的上下文中调用每个领域处理程序。
- 如果我们想处理++事务之外的事情++，我们需要基于领域事件创建一个公共事件。我称之为领域事件通知，有些人称之为公共事件，但概念是一样的。
第二个最重要的事情是什么时候发布和处理领域事件?事件可以在聚合上的每个操作之后创建，所以我们必须发布它们:
- 在每个命令处理之后(但在提交事务之前)
- 在每个领域事件处理之后(但没有提交事务)
最后要考虑的是处理领域事件通知(公共事件)。我们需要找到一种方法在事务之外处理它们，这时发件箱模式就发挥作用了。
首先想到的是在每个命令处理程序的末尾发布事件并提交事务，而在每个领域事件处理程序的末尾只发布事件。但是，我们可以在这里尝试一个更优雅的解决方案，并使用装饰者模式（Decorator Pattern）。装饰器模式允许我们将处理逻辑包装在基础架构代码中，类似于面向切片编程和 .NET Core中间件的工作。
我们需要两个装修器。第一个将用于命令处理程序:
public class DomainEventsDispatcherCommandHandlerDecorator<T> : IRequestHandler<T, Unit> where T:IRequest
{
private readonly IRequestHandler<T, Unit> _decorated;
private readonly IUnitOfWork _unitOfWork;
public DomainEventsDispatcherCommandHandlerDecorator(
IRequestHandler<T, Unit> decorated,
IUnitOfWork unitOfWork)
{
_decorated = decorated;
_unitOfWork = unitOfWork;
}
public async Task<Unit> Handle(T command, CancellationToken cancellationToken)
{
await this._decorated.Handle(command, cancellationToken);
await this._unitOfWork.CommitAsync(cancellationToken);
return Unit.Value;
}
}
正如您所看到的，在第16行中发生了给定命令的处理(真正的命令处理程序被调用)，在第18行中有一个工作单元提交（Unit of Work）。UoW commit发布领域事件并提交现有事务:
public class UnitOfWork : IUnitOfWork
{
private readonly OrdersContext _ordersContext;
private readonly IDomainEventsDispatcher _domainEventsDispatcher;
public UnitOfWork(
OrdersContext ordersContext,
IDomainEventsDispatcher domainEventsDispatcher)
{
this._ordersContext = ordersContext;
this._domainEventsDispatcher = domainEventsDispatcher;
}
public async Task<int> CommitAsync(CancellationToken cancellationToken = default(CancellationToken))
{
await this._domainEventsDispatcher.DispatchEventsAsync();
return await this._ordersContext.SaveChangesAsync(cancellationToken);
}
}
根据前面描述的假设，我们还需要领域事件处理程序的第二个装饰器，它只会在最后发布领域事件，而不提交数据库事务:
public class DomainEventsDispatcherNotificationHandlerDecorator<T> : INotificationHandler<T> where T : INotification
{
private readonly INotificationHandler<T> _decorated;
private readonly IDomainEventsDispatcher _domainEventsDispatcher;
public DomainEventsDispatcherNotificationHandlerDecorator(
IDomainEventsDispatcher domainEventsDispatcher,
INotificationHandler<T> decorated)
{
_domainEventsDispatcher = domainEventsDispatcher;
_decorated = decorated;
}
public async Task Handle(T notification, CancellationToken cancellationToken)
{
await this._decorated.Handle(notification, cancellationToken);
await this._domainEventsDispatcher.DispatchEventsAsync();
}
}
最后要做的是在IoC容器中配置我们的装饰器(以Autofac为例):
builder.RegisterGenericDecorator(
typeof(DomainEventsDispatcherNotificationHandlerDecorator<>),
typeof(INotificationHandler<>));
builder.RegisterGenericDecorator(
typeof(DomainEventsDispatcherCommandHandlerDecorator<>),
typeof(IRequestHandler<,>));
将领域事件通知添加到发件箱
我们要做的第二件事是保存关于希望在事务外部处理的领域事件的通知。为此，我们使用发件箱模式的实现:
var domainEventNotifications = new List<IDomainEventNotification<IDomainEvent>>();
foreach (var domainEvent in domainEvents)
{
Type domainEvenNotificationType = typeof(IDomainEventNotification<>);
var domainNotificationWithGenericType = domainEvenNotificationType.MakeGenericType(domainEvent.GetType());
var domainNotification = _scope.ResolveOptional(domainNotificationWithGenericType, new List<Parameter>
{
new NamedParameter("domainEvent", domainEvent)
});
if (domainNotification != null)
{
domainEventNotifications.Add(domainNotification as SeedWork.IDomainEventNotification<IDomainEvent>);
}
}
domainEntities
.ForEach(entity => entity.Entity.ClearDomainEvents());
var tasks = domainEvents
.Select(async (domainEvent) =>
{
await _mediator.Publish(domainEvent);
});
await Task.WhenAll(tasks);
foreach (var domainEventNotification in domainEventNotifications)
{
string type = domainEventNotification.GetType().FullName;
var data = JsonConvert.SerializeObject(domainEventNotification);
OutboxMessage outboxMessage = new OutboxMessage(
domainEventNotification.DomainEvent.OccurredOn,
type,
data);
this._ordersContext.OutboxMessages.Add(outboxMessage);
}
提醒一下，我们发件箱的数据保存在同一个事务中，这就是为什么保证“至少一次(At-Least-Once)”交付。
实现流步骤
此时，我们可以只关注应用程序逻辑，而不需要担心基础设施问题。现在，我们只实现特定的流步骤:
- 当订单被放置，然后创建付款:
public class OrderPlacedDomainEventHandler : INotificationHandler<OrderPlacedEvent>
{
private readonly IPaymentRepository _paymentRepository;
public OrderPlacedDomainEventHandler(IPaymentRepository paymentRepository)
{
_paymentRepository = paymentRepository;
}
public async Task Handle(OrderPlacedEvent notification, CancellationToken cancellationToken)
{
var newPayment = new Payment(notification.OrderId);
await this._paymentRepository.AddAsync(newPayment);
}
}
- 下单后发送电子邮件:
public class OrderPlacedNotification : DomainNotificationBase<OrderPlacedEvent>
{
public OrderId OrderId { get; }
public OrderPlacedNotification(OrderPlacedEvent domainEvent) : base(domainEvent)
{
this.OrderId = domainEvent.OrderId;
}
[JsonConstructor]
public OrderPlacedNotification(OrderId orderId) : base(null)
{
this.OrderId = orderId;
}
}
public class OrderPlacedNotificationHandler : INotificationHandler<OrderPlacedNotification>
{
public async Task Handle(OrderPlacedNotification request, CancellationToken cancellationToken)
{
// Send email.
}
}
- 当付款创建后，发送电子邮件:
public class PaymentCreatedNotification : DomainNotificationBase<PaymentCreatedEvent>
{
public PaymentId PaymentId { get; }
public PaymentCreatedNotification(PaymentCreatedEvent domainEvent) : base(domainEvent)
{
this.PaymentId = domainEvent.PaymentId;
}
[JsonConstructor]
public PaymentCreatedNotification(PaymentId paymentId) : base(null)
{
this.PaymentId = paymentId;
}
}
public class PaymentCreatedNotificationHandler : INotificationHandler<PaymentCreatedNotification>
{
public async Task Handle(PaymentCreatedNotification request, CancellationToken cancellationToken)
{
// Send email.
}
}
下图是整个流程:
总结
在这篇文章中，我描述了如何在深系统中以响应式方式处理命令和领域事件。
总的来说，为此目的使用了以下概念:
- 用于事件分派和事务边界管理的装饰器模式
- 用于在单独事务中处理事件的发件箱模式
- 工作单元模式（Unit of Work Pattern）
- 领域事件通知(公共事件)保存到发件箱
- 基本DDD构建块——聚合和领域事件
- 最终一致性
源代码
如果你想看到完整的工作示例——查看我的GitHub存储库
其它资源
The Outbox: An EIP Pattern（发件箱:EIP模式） – John Heintz
Domain events: design and implementation（领域事件:设计和实现） – Microsoft