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