关于聚合设计与cqrs

记得在去年的时候，也就是14年下半年的时候，那个时候第一次系统得学习领域驱动设计。在此以前，从《企业应用架构模式》中对领域驱动的设计，有所耳闻，并本身瞎摸索实践了，有大概一年。

后来，啃《领域驱动设计》一书，对其中的构件有了一些系统的了解，可是，仍然缺少经验。当时，用面向对象设计的原则来划分聚合，用四分法来划分聚合，查cqrs，其实都感受有些无力。通过两三个小项目的磨合，对其中的一些坑和原则，已有一些体会。直到后来，啃了《实现领域驱动设计》。书中对各类设计进行了至关详细的描述，并有代码示例，可是，却以为书中说的并不尽然。此时，咱们已经对领域驱动设计，其中构件的使用，有了至关的本身的理解。可是，总以为哪里味道不对。

记得曾经查cqrs架构时，查到一个架构用二进制序列化对象，严格得仅用ID进行聚合加载。当时，咱们其实很想用这个架构，可是，存在两个问题。

一、若是聚合结构变了，数据怎么处理

二、若是我想经过非ID查询聚合怎么处理

其实，主要矛盾仍是第一条。

当时，咱们还在用c#，看似，这个问题是无解的，因此就没有继续了。

这个问题，一直困扰我到了今天。

而，就在今天，忽然想到，聚合，为何会变。聚合，是用来执行业务的。业务的执行，在聚合中，引起，聚合的变化，而全部的查询数据，均和聚合结构无关。

因此，当聚合的职责，足够单一，它基本上是不会发生变化的。

而，当咱们想要加什么东西时，会作的，是增长聚合，须要改变业务时，要作的，是修改领域服务，聚合，是至关稳定的存在。

因此，《实现领域驱动设计》中，才会推荐在一个事务中仅操做一个聚合吧。由于，聚合，支撑业务操做，其余操做都会用领域事件触发。

而反思这点，全部的查询，均使用领域事件同步的数据，业务数据不可被查询，仅可被当作聚合，在聚合被加载的时候使用

那么彷佛，咱们的架构，在向纯粹的cqrs方向发展。

来自为知笔记(Wiz)