CQRS+ES项目解析-Equinox

今天我们来分析另一个开源的CQRS+ES项目:Equinox。该项目可以在github上下载并直接本地运行,项目地址:https://github.com/EduardoPires/EquinoxProject,该项目是基于 .net core 2.2的,开发语言、编码方式比Diary.CQRS更加新潮(CQRS+ES项目解析-Diary.CQRS),也更符合我们现在的开发习惯。

项目概览

首先通过github获取到项目源代码,打开项目文件,你会看到如下分层:

  • Presentation:展示层,UI在该层实现
  • Services:WebApi在该层实现,同样隶属于UI
  • Application:应用程序服务层,提供了对Domain层接口的封装,注重数据交换,DTO对象在该层定义
  • Domain:领域层,项目的核心部分,领域对象、领域服务在该层实现
  • Infra:基础设施层,项目的公共部分(数据访问)、切片(身份认证、消息发布、依赖注入)部分在该层实现

通过项目分层,我们已经对该项目有了一个大致的轮廓,当从Presentation、Services层接收到来自客户端的请求后,将会调用Application层的应用程序服务,应用程序服务将数据进行封装和转换,然后交给Domain层进行处理,Domain层则调用Infra相关的方法完成持久化、消息发布等功能。

Domain层

Domain层是Equinox项目的核心部分,Entity/ValueObject、Repository、UoW、Command、Event、EventStore等均在该层进行定义,我们来看一下。

Entity对象

实体对象,定义如下:

public abstract class Entity
{
    public Guid Id { get; protected set; }

    public override bool Equals(object obj)
    {
        //......
    }

    public static bool operator ==(Entity a, Entity b)
    {
        //......
    }

    public static bool operator !=(Entity a, Entity b)
    {
        //......
    }

    public override int GetHashCode()
    {
        //......
    }

    public override string ToString()
    {
        //......
    }
}

每一个实体对象都要具备ID属性,用来标记唯一性;重写了Equals方法、定义了==、!=操作符,用于两个对象的比较;重写了ToString方法、GetHashCode方法。

ValueObject

值对象,与实体对象进行区分,值对象没有Id属性。定义如下:

public abstract class ValueObject<T> where T : ValueObject<T>
{
    public override bool Equals(object obj)
    {
        //......
    }

    protected abstract bool EqualsCore(T other);

    public override int GetHashCode()
    {
        //......
    }

    protected abstract int GetHashCodeCore();

    public static bool operator ==(ValueObject<T> a, ValueObject<T> b)
    {
        //......
    }

    public static bool operator !=(ValueObject<T> a, ValueObject<T> b)
    {
        //......
    }
}

与Entity相似,定义了一些基本的操作方法。

Repository

数据仓储,用来进行数据访问,定义如下:

public interface IRepository<TEntity> : IDisposable where TEntity : class
{
    void Add(TEntity obj);
    TEntity GetById(Guid id);
    IQueryable<TEntity> GetAll();
    void Update(TEntity obj);
    void Remove(Guid id);
    int SaveChanges();
}

定义了对数据的基本操作,添加、更新、删除、查询等方法

UoW

工作单元,定义如下:

public interface IUnitOfWork : IDisposable
{
    bool Commit();
}

定义了Commit方法,当业务逻辑执行完成用,用于数据库事物

Command/CommandHandler 和 Event/EventHandler

CQRS和ES的核心部分,Command、Event被定义为消息,拥有共同的基类Message,分别定义如下:

Command:

public abstract class Command : Message
{
    public DateTime Timestamp { get; private set; }
    public ValidationResult ValidationResult { get; set; }

    protected Command()
    {
        Timestamp = DateTime.Now;
    }

    public abstract bool IsValid();
}

Event:

public abstract class Event : Message, INotification
{
    public DateTime Timestamp { get; private set; }

    protected Event()
    {
        Timestamp = DateTime.Now;
    }
}

与Command、Event对应的处理程序用来处理相应的业务逻辑,此处不在介绍。感兴趣的朋友可以参照上篇文章进行了解。

EventStore

EventStore也是ES的核心内容,负责对事件的存储、提取工作。在Equinox项目中,EventStore的定义如下:

public interface IEventStore
{
    void Save<T>(T theEvent) where T : Event;
}

额?只有一个Save方法,这不符合逻辑,只能进行事件的存储,而没有事件的查询。通过查阅项目的其它代码,我发现事件的查询则是通过EventStoreRepository来实现的,这一点不太符合我们的开放封闭原则和模块化思想。作者可能是想着对事件的操作也遵循CQRS模式吗?这就未可知了。

Bus

消息通信,Equinox项目中使用MediatR实现的基于内存的消息通信。定义如下:

public interface IMediatorHandler
{
    Task SendCommand<T>(T command) where T : Command;
    Task RaiseEvent<T>(T @event) where T : Event;
}

Infra层

基础设施层里面,定义了Domain层接口的实现,例如Data中实现了仓储、工作单元,Bus中实现了InMemoryBus等。由于都是非常简单的实现,不再展开介绍。

Application层

应用程序服务层有两个作用,封装底层(Infra、Domain)的操作,对UI层(Presentation、Services)数据进行转换,它是UI层与Domain层的桥梁。此处不再展开介绍。

UI层

Equinox项目中,UI层由两部分组成,分别是Presentation和Services,其中展示层提供了界面操作的功能,Services层提供了接口访问的功能,这两个项目采用MVC和WebApi技术,不再展开介绍。

Equinox项目总结

通过分析Equinox项目的结构和代码,我们可以发现,这个项目并不是很完善,作者所说的不要用在生产环境是实话。

在这个项目中,对于ES的实现并不是很优雅,首先EventStore的操作,未提供查询事件的接口,从而导致了需要通过Repository来获取Event,破坏了EventStore的完整性;其次该项目没有完成事件重放功能,我们只能通过事件查看到数据的变更,但是无法通过重放来获取项目的某个时段的状态的功能;最后,Equinox项目未实现读写分离,对于数据的查询和增加更新等操作都混合在一个Repository中,不利于我们进行读写分离。

以上请大家参考。

转载于:https://www.cnblogs.com/youring2/p/11110753.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
CQRS(Command Query Responsibility Segration)架构,大家应该不会陌生了。简单的说,就是一个系统,从架构上把它拆分为两部分:命令处理(写请求)+查询处理(读请求)。然后读写两边可以用不同的架构实现,以实现CQ两端(即Command Side,简称C端;Query Side,简称Q端)的分别优化。CQRS作为一个读写分离思想的架构,在数据存储方面,没有做过多的约束。所以,我觉得CQRS可以有不同层次的实现,比如: 1.CQ两端数据库共享,CQ两端只是在上层代码上分离;这种做法,带来的好处是可以让我们的代码读写分离,更好维护,且没有CQ两端的数据一致性问题,因为是共享一个数据库的。我个人认为,这种架构很实用,既兼顾了数据的强一致性,又能让代码好维护。 2.CQ两端数据库和上层代码都分离,然后Q的数据由C端同步过来,一般是通过Domain Event进行同步。同步方式有两种,同步或异步,如果需要CQ两端的强一致性,则需要用同步;如果能接受CQ两端数据的最终一致性,则可以使用异步。采用这种方式的架构,个人觉得,C端应该采用Event Sourcing(简称ES)模式才有意义,否则就是自己给自己找麻烦。因为这样做你会发现会出现冗余数据,同样的数据,在C端的db中有,而在Q端的db中也有。和上面第一种做法相比,我想不到什么好处。而采用ES,则所有C端的最新数据全部用Domain Event表达即可;而要查询显示用的数据,则从Q端的ReadDB(关系型数据库)查询即可。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值