【问题标题】:Identifying Aggregates when some entity is shared?共享某个实体时识别聚合?
【发布时间】:2017-11-28 17:20:17
【问题描述】:

假设我们有一个简单的数据结构:

InterfaceNetwork Printer 都有 EndPoint,它存储在不同的表中(强制执行 FK)。例如,Interface 要求 EndPoint’s 端口号介于:1000-2000 之间,Network Printer 要求端口号介于:2000-3000 之间。这让我觉得EndPoint 不能是聚合根,因为我们真的不需要直接访问它,也不想在不知道其上下文的情况下直接更改端点值。每this post:如果某物属于一个聚合,那么其他聚合可能会将其称为只读数据。是否意味着EndPoint 不能属于Interface Network Printer?或者它仍然可以,在我的情况下,相同的EndPoint 实例永远不会在两个聚合之间共享。所以InterfaceNetwork Pritner 总是会更新自己的EndPoint 并且不会发生一致性冲突?听起来对吗?

【问题讨论】:

    标签: c# domain-driven-design domain-model


    【解决方案1】:

    您尚未解释您的域,但对我来说,EndPoint 听起来根本不像一个实体,而是一个值(不可变)。更改端点只需将整个旧的EndPoint 值替换为新值即可。不可变值可以在聚合实例之间共享而不会出现问题,因为它们无法更改。

    不过,如果 EndPoint 一定是一个实体,那么只要 instances 不跨聚合共享就可以了。在多个聚合中使用相同的种类实体没有任何限制。

    【讨论】:

    • 谢谢,听起来有些东西仍然可以表示为 ValueObject,即使它实际上存储在带有 ID 字段的表中。 ID 只是没有在域级别公开?
    • @Tenek 你不能简单地将数据放在同一个表中吗?我的意思是,即使它是一个值,您也可以拥有一个专用的端点表,但是从持久性模型的角度来看,它将是一个实体,而从模型的角度来看,它将是一个值(很可能带有隐藏的 ID)。
    • 数据来自旧版数据库。现在 EndPoint 表是从 3 个不同的地方引用的,但值永远不会共享。我将为域对象做隐藏的 Id 字段,甚至完全避免它,因为无论如何都可以通过存储库从其上下文中查找 EndPoint。将 EndPoint 作为值对象帮助我避免暴露其存储库并简化整个结构。感谢您的建议!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-01-30
    • 2011-07-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多