【问题标题】:one repository for each root aggregate entity in domain driven design域驱动设计中每个根聚合实体的一个存储库
【发布时间】:2013-01-20 22:30:52
【问题描述】:

如果您遵循存储库模式,他们...说为每个根聚合实体创建一个存储库。

这意味着当我有这个模型时:

客户有订单 订单有产品 产品有供应商

等等……

这意味着我有 4 个存储库,它们被放入一个存储库中。客户是根实体。

我是不是误会了什么?

【问题讨论】:

    标签: domain-driven-design repository-pattern aggregateroot


    【解决方案1】:

    每个聚合都应该有一个存储库是正确的。但是,可能会有所不同的是您域中的聚合集。客户/订单/产品/供应商模型可以通过多种方式分解为聚合。分解为聚合取决于多种因素,并取决于手头的领域。

    聚合应该是一个一致性边界,这意味着它定义了哪些实体集在与这些实体关联的行为的上下文中应该是一致的。鉴于此约束,应消除聚合之间的对象引用并用身份引用替换。

    在您的模型中,客户、订单、产品和供应商可能是不同的聚合体,因此需要单独的存储库。即使客户是聚合根(客户聚合的一部分)并且订单取决于客户,但这并不意味着客户存储库应该包含订单存储库。订单存储库应该是完全独立的,因为订单是订单聚合的根。

    查看Effective Aggregate Design by Vaughn Vernon,深入了解如何设计聚合。

    【讨论】:

    • 请您更正一下:“...因为订单是订单聚合的聚合根”
    • 我稍微改变了措辞,但我不确定你想要更正什么?
    • hm 我想我不明白为什么订单是订单聚合的根。你能告诉我订单在哪里不是订单聚合的根吗?感谢我为它添加书签的链接。
    • 您有一个名为 Order 的聚合,它代表一个订单。每个聚合都有一个根实体,在订单聚合的情况下,它就是订单实体。行项目可以是订单聚合中的实体,但它不是聚合的根。
    • 好的,我认为订单聚合的根实体是客户实体...看来我必须了解更多信息 ;-)
    【解决方案2】:

    如上所述,您有 4 个相关实体,并且存储库为所有这些相关实体实现事务上下文。

    【讨论】:

    • 问题是关于 DDD 而不是实体和数据模型
    猜你喜欢
    • 1970-01-01
    • 2017-09-07
    • 1970-01-01
    • 1970-01-01
    • 2010-11-01
    • 2010-11-30
    • 2019-06-27
    • 2011-04-26
    • 1970-01-01
    相关资源
    最近更新 更多