Typed Message模式与Event Sourcing

时间:2023-01-30 10:06:34

引言

在《设计模式沉思录》(Pattern Hatching: Design Patterns Applied,[美]JohnVlissides著)一书的第4章中,围绕事件Message传递的推-拉模型(Push-Pull),谈到了一个最初被称为Multicast,之后被定型为Typed Message的设计模式。

该模式的初衷是希望得到一个可扩展的、类型安全的事件传递机制,并能符合两点要求:

  • 通过推模型来将事件传递给消费者。
  • 特有的每个事件只需要最多新增一个类,而不需要对已有代码进行修改。

在阅读过程中,由于Event Sourcing中围绕领域事件Domain Event建立的机制,与这一模式非常近似,因此记录如下。

Typed Message模式

意图

将信息封装在一个对象中,从而使信息的传递能够以一种类型安全的方式进来。客户可以对对象进行扩展,以便向对象中增添信息,同时无需牺牲类型安全性。

动机

强调对事件的封装扩展,而不再强调通知的过程。

适用场景(需要以下三条全部符合)

  • 一些类的对象可能希望收到来自其他对象的消息。
  • 信息的结构和复杂度是任意的,而且可能会随着软件的逐步发展而发生变化。
  • 信息的传递应该是静态安全的。

结构图

Typed Message模式与Event Sourcing

参与者

  • Message:对Sender发给Receiver的信息进行封装。
  • Sender:维护对Receiver对象的引用,实现一个或多个涉及将消息发送给接收者的操作。
  • AbstractReceiver:定义用来接收Message对象的接口。
  • Receiver:实现一个或多个AbstractReceiver接口。

协作

  • Sender创建Message的实例,并将它传递给相应的Receiver。
  • Message是被动的,它不会发起它与Sender或者Receiver之间的通信。

效果

  • 信息的传递能以一种类型安全的方式进行,而且是可扩展的,无需进行向下转型或使用switch语句。
  • 当和Observer模式结合使用时,可以支持隐式调用。
  • 如果编程语言不支持多重(接口)继承,那么将难以运用本模式。
  • 可能会产生非常复杂的继承图。

关于Typed Message与Observer的争论

不得不提的是,由于Typed Message与Observer两种模式的应用场合、注册与通知的方式等存在诸多相似,因此即便是在GoF的四人组与作者之间,围绕Typed Message模式能否单独作为一种模式存在、它是否只是Observer的一种变体而引发的争论,也持续了相当长的时间,在该书第4章中详细描述了这一过程。这段争论当中,有一句话,我认为是点到了关键:

我认为它不是Observer的变体,原因在于Observer知道它的Subject,而Multicast中的处理程序并不需要知道它们的事件源。

正是由于这个原因,所以在Typed Message模式里,Receiver并不清楚Sender的具体情况。Receiver只关心Sender发出的Message,并且在Receive方法里完成实际的事件处理操作。

在Event Sourcing中的映射

相似点

细思之下,Event Sourcing中Event、Aggregate、EventHandler之间的关系,与Typed Message模式中的Message、Sender、Receiver何其相似:

  • Event从Aggregate发出,由EventHandler接收。
  • Event本身只是通信内容的载体。
  • 随着软件功能的发展,Event的家族会不断丰富。
  • Aggregate负责创建Event的实例,并将它传递给EventHandler。
  • EventHandler并不关心发出Event的那个Aggregate究竟什么样,只关心Event承载的信息,并借此完成自己的职责。

所以,对上图作简单修改,即可得到下图:

Typed Message模式与Event Sourcing

代码实现

借用《Exploring CQRS and Event Sourcing》中Conference案例的代码作为参考:

Event

Event的实现,是简单的、带版本Version的、若干Property组成的类。

public class OrderPlaced : VersionedEvent

{

    public Guid ConferenceId { get; set; }

    public IEnumerable<SeatQuantity> Seats { get; set; }

    public DateTime ReservationAutoExpiration { get; set; }

    public string AccessCode { get; set; }

}

Aggregate

在聚合Order里,在Order的构造子中触发一个OrderPlaced事件。

public class Order : EventSourced

{

    ... ...

    public Order(Guid id, Guid conferenceId, IEnumerable<OrderItem> items, IPricingService pricingService)

        : this(id)

    {

   ... ...

        this.Update(new OrderPlaced

        {

            ConferenceId = conferenceId,

            Seats = all,

            ReservationAutoExpiration = DateTime.UtcNow.Add(ReservationAutoExpiration),

            AccessCode = HandleGenerator.Generate(6)

        });        

        ... ...

    }    

    ... ...

}

IEventHandler

这里定义的接口IEventHandler,对应图中的抽象类EventHandler。(C#支持类的多接口实现,是Typed Message模式应用的关键之一)

public interface IEventHandler<T> : IEventHandler

        where T : IEvent

{

    void Handle(T @event);

}

EventHandler

在Conference案例中,主要有两种场景下实现的EventHandler。

一类是在Command端,从Event Queue中消费Event,或者Process Manager需要的,相对独立的EventHandler。

public class OrderEventHandler :

        IEventHandler<OrderPlaced>,

        IEventHandler<SeatUnassigned>

{

    ... ...

    public void Handle(OrderPlaced @event)

    {

        using (var context = this.contextFactory.Invoke())

        {

            context.Orders.Add(new Order(@event.ConferenceId, @event.SourceId, @event.AccessCode));

            context.SaveChanges();

        }

    }

    ... ...

另一类是在Query端,需要更新读模型时,嵌入视图生成器中的EventHandler。

public class PricedOrderViewModelGenerator :

        IEventHandler<OrderPlaced>,

        IEventHandler<SeatUpdated>

{

    .... ....

    public void Handle(OrderPlaced @event)

    {

        using (var context = this.contextFactory.Invoke())

        {

            var dto = new PricedOrder

            {

                OrderId = @event.SourceId,

                ReservationExpirationDate = @event.ReservationAutoExpiration,

                OrderVersion = @event.Version

            };

            context.Set<PricedOrder>().Add(dto);

            try

            {

                context.SaveChanges();

            }

            catch (DbUpdateException)

            {

                Trace.TraceWarning("Ignoring OrderPlaced message.", dto.OrderId, @event.Version);

            }

        }

    }

    .... ....

}

结语

同样以《设计模式沉思录》作为结束… …

  • 用代码量来衡量开发人员的效率,实现是一项很糟糕的标准。一个良好的设计恰恰相反——它简洁而优雅。
  • 期望开发人员抽出时间来专心思考是不切实际的,但你能够做的是将积累的经验逐渐记录下来。
  • 尽可能多看一些其他的系统。分析一个系统时,试着去辨认你已经知道的模式。