关于聚合设计与cqrs

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

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

1、如果聚合结构变了，数据怎么处理

2、如果我想通过非ID查询聚合怎么处理

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

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

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

而，就在今天，突然想到，聚合，为什么会变。聚合，是用来执行业务的。业务的执行，在聚合中，引发，聚合的变化，而所有的查询数据，均和聚合结构无关。

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

而，当我们想要加什么东西时，会做的，是增加聚合，需要改变业务时，要做的，是修改领域服务，聚合，是相当稳定的存在。

所以，《实现领域驱动设计》中，才会推荐在一个事务中仅操作一个聚合吧。因为，聚合，支撑业务操作，其他操作都会用领域事件触发。

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

那么似乎，我们的架构，在向纯粹的cqrs方向发展。

来自为知笔记(Wiz)