请教编程技术对领域驱动设计的影响

15-03-25 abel
请问大牛们,在实际开发过程中,如何将JPA与领域驱动设计结合?

如果在领域驱动设计出来的的类上使用JPA注解是否可行?我们知道领域驱动模型分应用层,领域层,基础设施层等,如果在领域类上使用JPA注解的话,那领域驱动模型岂不是在基础设施层了?

领域类是否可以用做DTO(数据传输对象)呢?

[该贴被abel于2015-03-25 15:22修改过]

banq
2015-03-25 15:35
DDD实现是CQRS/Eventsourcing路线,JPA等ORM不适合DDD,主要不能完全解决对象与关系数据库的不匹配:

ORM是明显的反模式

为什么要使用Event Sourcing

abel
2015-03-26 21:36
请问使用CQRS/eventsourcing如何实现事务?

比如,同时保存顾客信息和订单信息,如果有其中任何一个信息保存失败,则回滚

banq
2015-03-27 08:43
2015-03-26 21:36 "@abel"的内容
如果有其中任何一个信息保存失败,则回滚 ...

ES保存的事件,不是状态,因此不能用我们通常理解的事务实现技术如回滚等实现,回滚是状态的回滚,而我们注重的是导致状态的事件,也就是原因,事件是因,状态是果,事件记录了以时间为顺序的逻辑因果关系,事件通过回放等方式实现类似回滚的事务机制。同时,ES也适合跨分布式实现事务机制:

使用Apache Samza对数据库进行彻底的"调教"

clonalman
2015-04-05 19:13
严格来说,领域模型不应该受到来自技术方面的影响,能改变领域模型的只有业务本身。经典DDD书里不是写的挺好的吗?直接用sql也能实现,并且sql语句也没有侵入领域模型。JPA直接挂在模型中,你模型必然要依赖于制定框架了,这就不大好了。用ES可以实现,用ORM也是可以的,只要保证ORM框架不侵入你的模型即可。如:可用配置(XML等)或约定

clonalman
2015-04-05 19:20
关于DTO,我领域模型里是没有DTO,但有VO哦

领域类还是要投射DTO的,但不需要一个领域类影射就搞一个或几个DTO,要区分场景。

abel
2015-04-20 13:34
有时候在想,既然有一些框架能带来快速的开发好处,为什么不用呢?但是用了就可能会侵入领域模型。这个还是要衡量利弊吧

猜你喜欢