领域驱动设计(DDD)实体更新及领域模型与DB模型分离实践疑问

你的设计思路完全符合DDD的规范，没有问题。

关于仓储返回值的疑问 #

仓储必须将查询到的DB模型转换为完整的富领域模型后再返回给上层调用方。
仓储的核心定位是领域层与持久化层的中介，对外只暴露面向领域的集合式访问接口，上层的应用服务、领域逻辑只需要依赖领域模型，完全不需要感知DB模型的存在。这种设计可以保证你的领域逻辑和基础设施完全解耦，后续不管是切换数据库类型、替换ORM框架，还是切回内存数据库做单元测试，上层业务代码都不需要做任何修改。
你当前的更新流程是完全正确的：从仓储拿到富领域模型后直接调用封装好的业务方法concert.sellTickets(3)，所有业务规则都收敛在领域模型内部，不会出现业务逻辑泄露到应用层的问题。

现有实现的优化建议 #

1. 领域模型重建时要保证完整性：从DB模型转换为领域模型的过程中，要确保所有关联的值对象、子实体都被正确构建，不能出现属性缺失导致领域方法执行异常的情况。比如sellTickets()需要校验剩余库存，转换时就必须保证库存字段被正确映射，不能漏传。
2. 映射逻辑集中维护：你目前使用的Adapter转换逻辑建议统一放在基础设施层，不要分散到多个仓储实现中，后续修改字段映射规则时只需要修改一处即可。
3. 后续如果切换到成熟ORM框架，可以直接配置ORM将查询结果直接映射到富领域模型，省掉手动编写转换逻辑的步骤，你当前用内存数据库手动实现转换的方案是完全合理的。

内容的提问来源于stack exchange，提问作者milandjukic88