DDD 中的聚合根持久化问题（使用关系型数据库）

不是你的数据模型设计错了，就是你的领域模型设计错了……

了解下领域模型和数据模型解耦合

@xiangwan #2 有没有好的文章，铁子，找了半天没找到。。。
@xuanbg #1 感觉都没错啊。。网上说的最好的方式是使用 mongodb 。。。

领悟模型有人也叫成业务模型，对象模型，可以换着搜搜
有个解藕思路是，在仓储层转换领域对象和数据对象
主要是转换下思维，不执意让数据表和领域模型完全对应。可以像上面提到的，在数据访问层进行转换

@xiangwan #4 俺用的 spring data jpa，也是想在数据访问层做做文章。

之前没用过 jpa 和 ddd，俺也在摸索中。。。

谢谢铁子给的思路，俺慢慢尝试。

我最近也在搞 ddd 费劲

@asanelder 不客气

@CoderGeek 准备放弃 ddd 了。
最近觉着 ddd 倾向把问题复杂化，不敏捷。

@CoderGeek
@xiangwan

搞了 2 个多星期的 DDD，一开始很不习惯，弄下来之后发现还是挺爽的

我最近也在搞 ddd 费劲
@xiangwan
真的需要业务专家 不是说技术的问题，
起码第一步不能画跑偏了

@CoderGeek ddd 有很多优点，但是在技术层面，“原教旨“ddd 用的方式很复杂，例如：事件溯源,命令查询分离；
“聚合根“也是一个好坏参半的解决方案，除了本贴持久化的问题，还面临选择是用充血模型还是贫血模型，大部分贫血模型的项目其实都是伪 ddd 。

@imherer 我尝试好多次 ddd 了，总感觉不够 ddd 。它的“战略工具”确实可以，前阵跟着微服务有火了一把

@xiangwan 战略工具 具体指什么 有相关文章或者 demo 吗？

聚合根是否需要落地是个问题. 有些可能是联合查询对外暴露, 聚合根落地的话简单的形式就是各个外键 id 存储

@xiangwan #10 确实，完全遵循原教旨很麻烦，但俺也是从中借鉴一些思想，比如领域模型，充血对象等等。

之所以想实践 DDD，就是感觉之前做的所有 Web 无关是 CRUD，实在是受不鸟啦！
@huifer #12 俺在使用 spring data jpa 做持久化，持续摸索中。。。

@xiangwan 我的想法是没有所谓绝对标准，不管什么架构模式都是一步步沉淀的 还是得明白业务领域，不说写什么的问题，起码前期梳理的全面 大模块不会跑偏， 这个东西确实需要有一定沉淀的业务人员和技术人员 要么连好事都算不上 浪费时间

@imherer
@xiangwan
取其精华，去其糟粕 ；有好有坏

我是参考 https://www.cnblogs.com/uoyo/p/12167224.html 的实践，有些落地难得地方需要妥协

聚合根和数据库对象之间通过 Converter 来 serialize 和 deserialize

@leoskey #16 感谢，俺看看

@iamppz #17 确实是一个方法，但俺想利用 ORM 直接将数据库对象映射到聚合根，多做一次转换好麻烦啊

@xiangwan #4
@iamppz #17

其实这种从领域对象到数据对象的转换就是因为关系型数据库中的数据模型无法完全匹配领域模型，而俺看 mongodb 的文档可以完全匹配，那么，是不是换成 mongodb 就没这种烦恼了呀

技术上使用 Spring Data 的话，它已经抽象了 DomainEvent，AggregrateRoot 处理，适用大多数 Spring Data 子项目，包括 Spring Data JPA, 请参考 Spring Data 文档。
https://docs.spring.io/spring-data/data-commons/docs/current/api/org/springframework/data/domain/DomainEvents.html
https://docs.spring.io/spring-data/data-commons/docs/current/api/org/springframework/data/domain/AbstractAggregateRoot.html


另外代码层面实现上，充分利用 Spring 特性，比如 ApplicationEvent 处理 Domain Event，Message Broker 来实现跨 Domain （不同的 BoundedContext ）数据同步。

Domain 建模，Aggregate Root 的颗粒度源于实践，怎么具体处理，取决你的长期经验。经验需要不断积累，不断试错和踩坑，技术架构也是需要不断演进的。理论上很多东西一看就明白，落地很难，比如 Single Reponsibility 拿到国内，细化接口规范后，有些人就只会比较字符数量，便得出结论是增加了任务量。

发现一篇不错 Spring Data 结合的文章，https://paucls.wordpress.com/2018/05/31/ddd-aggregate-roots-and-domain-events-publication/

例子： https://github.com/paucls/runbook-ddd-kotlin

Spring Data @DomainEvents 的使用，https://www.baeldung.com/spring-data-ddd

@kvkboy 手快不小心不小心发出去了，可以看看这个文章，挺有参考的价值。不过更多的还是需要看书，ddd 经典的两本一本理论一本落地

@kvkboy 六边形和洋葱不错，特别六边形，把系统进出接口进行隔离，感观比较清晰。

文章提到的 Cargo 例子作为 Eric 原书 DDD 的一部分，使用了 Spring 框架，现在已经有各种版本了。

Eclipse EE4J 官方也维护了一个基于 Java EE/Jakarta EE 规范的 Cargotraker.

https://github.com/eclipse-ee4j/cargotracker

简介： https://eclipse-ee4j.github.io/cargotracker/

@hantsy #20
@kvkboy #23

感谢二位铁子，文章俺都看了，也有一些思路了，正在实践中。。。

Ddd 是业务建模 不是数据建模 不懂业务还是不要玩

@asanelder 个人感觉跟数据库没有关系，你需要一个合适的 ORM，我用的 Spring Data JPA

@iamppz 理想的设计层面，Domain 建模不会考虑到数据库，到真正实现的时候才考虑。如果 Domain 模型与数据库有关系，就是 DDD 中的 Entity，最终要持久化，不得不考虑到数据库的问题。

国内的实践，直到现在很多人做项目或者产品还是本末倒置，需求一到，数据库 Schema 优先设计，使用一些工具自动生成 Entities （或者什么框架需要的类似的东西，这只是数据库的 Entities，与 Domain Model 中 Entities 无关）。从一开始就是面向数据库的，最终业务都是围绕数据存储。以前项目中经常遇到有谈业务的时候，没两句直接会想到数据库存放，页面一个搜索框，能够联想到联合查询等，完全脱离不了数据库思维。

@iamppz #29

俺就是用的 spring data jpa，但是也只是做 orm, m 和 domain object 还是要人工转化一下。

@hantsy #30

今天搞定 domain object 和 data object 的转化后，用充血模型写业务，有点爽啊~~~

@asanelder 用 DDD 充血模型确实爽。。但我还卡在怎么用 jpa 将 data object 与 domain object 进行转化。。目前打算用的是 mapStruct 进行转化。。
另外还有个问题，spring data jpa 中的 repository 只是用来查询 data object 了吧？我觉得它的 repository 与 DDD 的 repository 其实不是同一个概念了。。