architecture - 协调 DDD、 View 模型和性能

标签 architecture domain-driven-design ddd-repositories

我开始了解 DDD,并担心从持久性中检索实体对象然后在 UI 的 View 模型中重构它们的性能影响。

假设我有两个聚合根:

Person      Orders
------      -------
personId    orderId
name        personId

每个聚合根都有自己的存储库,负责整个聚合的基本 CRUD 操作。

假设 UI 需要以下列:
viewmodel
---------
personName
numberOfOrders

我可以想到两种填充此 View 模型的方法:
  • 急切加载所有人员实体,急切加载基于 personId 的所有订单,将加载的实体重组到 View 模型中。
  • 创建一个 JOIN/COUNT(orderId) 存储过程,并让数据库以与 View 模型相同的结构返回数据。

  • 显然,选项 1 可能是非常昂贵的操作,因为可能有多个人和多个订单导致 MULTIPLE 数据库调用。选项 2 将只需要一次数据库调用。

    如果选项 2 是首选(性能)选项,我应该在哪里存储这个“ View 模型”和所谓的“数据库调用”?在我可以实现的存储库之上是否有单独的“数据服务层”?或者这是关于 DDD 通常如何实现的反模式?

    基本上,我如何将复杂的 DDD 聚合与自定义 UI Viewmodels 保持一致,同时牢记性能?

    更新

    规范/查询对象

    在与 friend 的交谈中,他建议一种可能的解决方案是某种规范/查询对象模式。唯一的问题是我们必须在存储库级别实现这一点,需要我将人员和订单组合成一个大集合。出于事务一致性的原因,我通常会避免这种情况。

    最佳答案

    您可以引入一个专用的值对象和一个可以返回给定人员统计信息的存储库:

    // value object
    class PersonStatistics {
        String PersonName
        Int NumberOfOrders
        Money AverageOrderAmount
    }
    
    // repository
    interface PersonStatisticsProvider {
        PersonStatistics Get();
    }
    

    这类似于 read-model图案。

    关于architecture - 协调 DDD、 View 模型和性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/12049716/

    相关文章:

    sql-server - 标签的无连接表结构

    android - 整洁的架构——简单的 View 逻辑应该在 Presenter 上还是在 View 上?

    java - 在实现领域驱动设计时,您可以引用工厂中的其他聚合吗?

    .net - DDD 中与存储库的身份冲突

    architecture - CISC 机器 - 它们不只是将复杂的指令转换为 RISC 吗?

    java - 如何构建可扩展的多应用程序并能够扩展某些应用程序组件?

    asp.net - IQueryable & Repositories - 拿 2 个?

    javascript - 为复杂的关系域模型构建 Redux 状态

    domain-driven-design - 聚合根如何删除其子项之一?

    architecture - 确定 DDD 架构中的存储库和聚合大小以及责任