【问题标题】:Multiple domain objects and repositories to support different uses of the same entity?多个域对象和存储库来支持同一实体的不同用途?
【发布时间】:2013-07-18 23:00:55
【问题描述】:

我正在开发一个允许用户跟踪工作订单状态的应用程序。默认界面列出所有打开的工单,并允许用户更新单个工单的状态。此列表是“实时的”,因为它会在其他工作站上的其他用户进行更改时更新。

有一个不经常使用(但必需)的可选 UI,它将列出当天的所有工作订单(不包括在一天中的某个时间点打开的工作订单)。用户无法更改此列表,并且此列表是静态的,即显示列表时的快照,而不是“实时”。

从后端服务检索工作订单数据。可以根据需要更新服务合同。

我的问题是围绕 WorkOrder 实体的两个用例对域进行建模。我的表示层中将有两个视图和关联的视图模型,但我应该有两个独立的域对象和存储库吗?

附加信息:

  • “全部”视图很少访问,并且在业务结束时访问 一天,这个列表可能非常大,需要大量的 内存(如果缓存在客户端)。
  • “当前”视图通过以下方式与其他用户的更改保持同步 处理一个广播事件/通知,表明更改是 制作并刷新列表。

【问题讨论】:

    标签: domain-driven-design


    【解决方案1】:

    您不需要单独的 WorkOrder 实体,因为这两个视图中都存在相同的工作订单概念,但您可能需要不同的 read-models 来表示特定类型查询中的这些实体。读取模型是只读的、仅数据的对象,旨在适应特定查询。

    【讨论】:

    • 单一存储库?
    • 这并不重要,但我会从一个开始。此外,这些不是传统的存储库,因为它们只提供查询 - 没有持久性。您也可以将其称为 WorkOrderQueryService
    猜你喜欢
    • 2023-03-31
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-07-06
    • 1970-01-01
    • 1970-01-01
    • 2011-05-09
    相关资源
    最近更新 更多