DDD 关于 aggregate 的规则，是否 mongo 更适合使用呢

[qwzhang01]

DDD 中 aggregate 的规则：

1. 边界：聚合根定义了一组相关对象的边界。它们是一起被创建、修改和删除的对象的集合。聚合根负责保护和维护其内部对象的一致性和完整性。
2. 一致性：聚合根负责确保其内部对象之间的一致性。所有对聚合根的操作都应该通过聚合根进行，以确保内部对象的状态和关联关系保持一致。
3. 根实体：聚合根是聚合中的一个特殊对象，它代表整个聚合。聚合根具有唯一标识符，并且可以通过该标识符进行引用和访问。
4. 事务边界：聚合根定义了一组操作的事务边界。所有对聚合根的操作应该在同一个事务中进行，以确保数据的一致性和完整性。

这种思路，是不是更适用 mongo 实现，于 MySQL 比，天然一个记录就是一个 aggregate

[hbhswj]

其实存储技术应该是最简单的一环

[Leviathann]

hibernate 不就支持一个对象作为字段么

[thinkershare]

你的理解没什么，基于文档的数据库的确更加适合 DDD ，但是随之而来的问题是事务一致性。

[thinkershare]

没什么问题。

[ihuotui]

对于简单一个实体一个表的话，什么数据库都可以，但是一个根对应多个实体（比较复杂的根），确实需要事务（或者保证一致性的支持，但是自己实现事务不如数据库的事务）。

[Qjues]

1. mysql 和 mongodb 的关键区别关系型和结构化的点上。
2. mongo 所谓的文档概念，在 mysql 中也可以通过 json 字段实现。
3. 复杂业务一个聚合会有多个关联实体，会出现通过实体反向查询聚合场景。ddd 的聚合思想优势更多体现在增删改的入口管理。

[cubecube]

mango 一无是处，放弃吧，所有的第一代 nosql 除了 redis ，目前都没啥太大的意义了。在 CPU 性能暴增+全闪存存储下， 关系型数据库根本没有啥缺点

[Desdemor]

aggregate 跟你用哪个数据库无关吧, 他是聚合的每个实体

[zhengchengdong]

第一，所谓聚合罗里吧嗦一大堆定义，其本质就是面向对象设计的 “封装性”
第二，mongodb 官网早期首页上赫然写着 “mongodb 的文档性设计天然契合习惯于对象思维的程序员”，只不过现在都被广告代替了
所以，你是对的
另外，没什么可担心的，都是设计思想问题，DDD 是个设计思想