[设计模式] Typed Message模式与Event Sourcing

引言

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

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

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

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

Typed Message模式

意图

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

动机

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

适用场景（需要以下三条全部符合）

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

结构图

参与者

• 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承载的信息，并借此完成自己的职责。

所以，对上图作简单修改，即可得到下图：

代码实现

借用《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);

            }

        }

    }

    .... ....

}

结语

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

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