转载

DDD落地篇--实践问题

实践过程中遇到的问题

持续更新，也欢迎一起讨论，好问题也会更新上去

1.mq包的位置

其实mq receiver应该和对外api实现、job、web一样单独一个module拿到core外面。放在一起是为了方便和mq provider一起查看。

2.领域层的一些通用职能该怎么办

像发布领域事件的接口、发消息的接口、标识实体、值对象的接口等。我抽出一个shared包单独放这些公有抽象的类。

3.领域模型和数据模型的转换

其实个人还是推荐实体模型和数据模型分开维护，但是这样基础设施层要写很多转换和处理的代码。后来持久化机制采用JPA解决这一问题。

4.事务管理与事件处理

事务的管理应该放在应用层，并且应遵循一个事务只更新一个聚合的原则。事务一致性应该用最终一致性去保证。所以我采用spring event的@TransactionalEventListener保证前一个事务提交了才执行后续事件。然后通过事件的异常处理机制保证事件至少消费一次。

5.到底要不要使用事件

首先用事件的话会增加编程的复杂度，还要在为事件实现相关的机制。如果用事件只是为了调用各个聚合的话，直接放在应用服务里去编排就好了。或者直接考虑用消息中间件实现。

6.持久化机制用jpa的话，query操作怎么办

考虑queryDSL、JOOQ这种DSL风格的轻量级框架

7.领域服务应该放在哪里

一开始根据DIP原则，把接口放在领域层，实现放在了基础设施层。后来感觉业务逻辑相关还是要放在领域层，而且这个接口也不会有多个实现的场景，就改为直接把实现放在领域层，其他服务直接注入实现。

原文 https://segmentfault.com/a/1190000021159719

正文到此结束

所属分类： Java 编程技术

本文标签： NSA 数据模型一致性 IDE http 模型数据 core id provider MQ https list IO ip 代码 Action web API Job spring 管理 JPA
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。