关于聚合设计与cqrs

记得在去年的时候,也就是14年下半年的时候,那个时候第一次系统得学习领域驱动设计。在此之前,从《企业应用架构模式》中对领域驱动的设计,有所耳闻,并自己瞎摸索实践了,有大概一年。
后来,啃《领域驱动设计》一书,对其中的构件有了一些系统的了解,但是,仍然缺乏经验。当时,用面向对象设计的原则来划分聚合,用四分法来划分聚合,查cqrs,其实都感觉有些无力。经过两三个小项目的磨合,对其中的一些坑和原则,已有一些体会。直到后来,啃了《实现领域驱动设计》。书中对各种设计进行了相当详细的描述,并有代码示例,但是,却觉得书中说的并不尽然。此时,我们已经对领域驱动设计,其中构件的使用,有了相当的自己的理解。但是,总觉得哪里味道不对。
记得曾经查cqrs架构时,查到一个架构用二进制序列化对象,严格得仅用ID进行聚合加载。当时,我们其实很想用这个架构,但是,存在两个问题。
1、如果聚合结构变了,数据怎么处理
2、如果我想通过非ID查询聚合怎么处理
其实,主要矛盾还是第一条。
当时,我们还在用c#,看似,这个问题是无解的,所以就没有继续了。
这个问题,一直困扰我到了今天。
而,就在今天,突然想到,聚合,为什么会变。聚合,是用来执行业务的。业务的执行,在聚合中,引发,聚合的变化,而所有的查询数据,均和聚合结构无关。
所以,当聚合的职责,足够单一,它基本上是不会发生变化的。
而,当我们想要加什么东西时,会做的,是增加聚合,需要改变业务时,要做的,是修改领域服务,聚合,是相当稳定的存在。
所以,《实现领域驱动设计》中,才会推荐在一个事务中仅操作一个聚合吧。因为,聚合,支撑业务操作,其他操作都会用领域事件触发。
而反思这点,所有的查询,均使用领域事件同步的数据,业务数据不可被查询,仅可被当做聚合,在聚合被加载的时候使用
那么似乎,我们的架构,在向纯粹的cqrs方向发展。


相关文章

适配器模式将一个类的接口转换成客户期望的另一个接口,使得原本接口不兼容的类可以相互合作。
策略模式定义了一系列算法族,并封装在类中,它们之间可以互相替换,此模式让算法的变化独立于使用算法...
设计模式讲的是如何编写可扩展、可维护、可读的高质量代码,它是针对软件开发中经常遇到的一些设计问题...
模板方法模式在一个方法中定义一个算法的骨架,而将一些步骤延迟到子类中,使得子类可以在不改变算法结...
迭代器模式提供了一种方法,用于遍历集合对象中的元素,而又不暴露其内部的细节。
外观模式又叫门面模式,它提供了一个统一的(高层)接口,用来访问子系统中的一群接口,使得子系统更容...