我一直在读有关DDD、事件来源(ES(和CQRS的文章。我意识到，如果我们考虑ES和CQRS，骨料一直是设计的核心。如果我错了，请纠正我，但我学到了：
- 每个命令将对应一个聚合，这可以帮助我们定义命令
- 每个事件流对应一个聚合，使我们可以轻松定义事件结构
现在我只是在想，如果可能的话，有没有任何工具或方法可以帮助我们从一些输入中识别现有应用程序中的聚合？我相信"；历史事务日志"；以及"；数据库模式"；因为输入确实有助于获得关于聚集体的某些结构的一些知识。我可能又错了，但有没有人尝试过类似的方法，让软件工程师更容易找到聚合的过程？
如果您正在谈论从某些现有系统(可能是您希望用遵循域驱动设计的系统来取代的系统(中获取历史事务日志和DB模式，我强烈建议不要使用这种方法。
对于现有的实现，事务日志和模式充其量只是域的编码，并且可能已经丢弃了一些上下文，并以某种方式扭曲了域以适应DB的约束。如果这些是你发现域的主要基础，那么最好的情况可能是你最终得到了一个在某些方面较差的现有系统的克隆。
找到聚合的最简单方法是查看所需的操作，并跟踪这些操作的顺序如何相互影响(例如"该命令的成功如何影响该后续命令是否成功"；如果答案是"无效"，则这些命令几乎肯定不是同一集合，因为在CQRS风格的DDD中，集合的目的是确定命令是成功还是失败(。这通常需要与领域专家合作来探索该领域，例如通过事件风暴(或一些类似的技术(。