我过去是根据贫乏领域模型设计应用程序的,所以我有许多存储库对象,这些对象被注入到大型的,可识别事务的服务层。此html" target="_blank">模式称为事务脚本。由于它会导致过程代码,因此不认为这是一种好习惯,因此我想继续进行领域驱动的设计。
在阅读了网上的几篇文章,听过克里斯·理查德森(Chris
Richardson)关于Parleys的演讲并阅读了《行动中的POJO》中DDD的各章之后,我想我已经了解了很多。
问题是,我不知道如何在应用程序中组织事务。Chis Richardson在他的书中指出:
表示层通过直接或间接通过外观调用域模型来处理来自用户浏览器的HTTP请求,正如我在上一章中所描述的那样,它是POJO或EJB。
到目前为止,还不错,但是InfoQ文章上的Srini
Penchikala 指出:
一些开发人员更喜欢在DAO类中管理事务,这是一个糟糕的设计。这会导致事务控制的粒度太细,从而无法灵活地管理事务跨越多个域对象的用例。服务类别应处理交易;这样,即使事务跨多个域对象,服务类也可以管理事务,因为在大多数用例中,服务类都会处理控制流。
好的,因此,如果我正确理解这一点,则存储库类不应是事务性的,服务层(现在已经更薄)是事务性的(因为它以前是事务脚本模式)。但是,如果表示对象直接被表示层调用,该怎么办?这是否意味着我的域对象应该具有事务行为?以及如何在Spring或EJB环境中实现它?
这对我来说似乎很奇怪,所以如果有人可以澄清这一点,我会很高兴。谢谢。
到目前为止,我个人在Spring和Hibernate上应用DDD的观点是拥有一个无状态事务服务层并通过该层访问域对象。因此,我执行此操作的方式是域模型完全不了解事务,而事务完全由服务处理。
有一个示例应用程序可能对您有所帮助。看起来Eric Evans参与了它的创建。
我正在学习DDD概念,为了加强我的理解,我正在研究一些现实世界的例子。 我知道一个聚合应该只有一个通过根实体的入口点,一个聚合应该只有一个存储库(如果我完全理解错了,请纠正我) 现在假设有特定类型的消耗品,并且这些消耗品是从配送中心发送的。发送特定类型的消耗品取决于它们的数量,我的意思是,如果其中一个消费者对A型和B型的临界数量为10,并且这些项目的数量低于10,那么配送中心发送A型和B型消耗品。
null 到目前为止,很容易。如果我们试图将规范应用到存储库,而又不破坏DDD模式或存在性能问题,那么问题就会出现。 应用规范的可能方法: 1)经典方法:在领域层使用领域模型进行规范 null null 3)与2)类似,但将规范作为持久层的一部分 这不起作用,因为域层需要参考规范。它仍将取决于持久层。 我们将在持久层中拥有业务逻辑。这也违反了DDD模式 4)与3类似,但使用抽象规范作为接口 nul
Eric Evans在DDD中谈了很多关于模型进化的话题,所以重构似乎对DDD是必不可少的。当一个人拥有世界的关系持久化状态时,可以通过迁移来处理模型更改,从而更改数据库模式。 使用事件源时,如何应对模型更改?如果对聚合有不兼容的更改,这将阻止事件的重播,是否有某种最佳实践?还是只是不要?
本文向大家介绍谈一下领域驱动设计相关面试题,主要包含被问及谈一下领域驱动设计时的应答技巧和注意事项,需要的朋友参考一下 主要关注核心领域逻辑。基于领域的模型检测复杂设计。这涉及与公司层面领域方面的专家定期合作,以解决与领域相关的问题并改进应用程序的模型。在回答这个微服务面试问题时,您还需要提及DDD的核心基础知识。他们是: DDD主要关注领域逻辑和领域本身。 复杂的设计完全基于领域的模型。 为了改
本文向大家介绍什么是领域驱动设计(DDD)相关面试题,主要包含被问及什么是领域驱动设计(DDD)时的应答技巧和注意事项,需要的朋友参考一下 专注于核心领域逻辑 在模型上找到综合的设计 不断与领域专家合作,改进应用程序模型并解决与领域相关的问题
本文向大家介绍php事件驱动化设计详解,包括了php事件驱动化设计详解的使用技巧和注意事项,需要的朋友参考一下 本文实例讲述了php事件驱动化设计。分享给大家供大家参考,具体如下: 最近在做一个需要用到异步php的项目, 翻阅php源码的时候,发现了三个没有用过的模块,sysvsem,sysvshm,sysvmsg,一番研究以后,受益非浅。 在php中有这么一族函数,他们是对unix的v ipc函