use*_*699 3 domain-driven-design repository-pattern
我已经有了一个问题,我已经阅读了几个月,因为我已经阅读过有关DDD,模式和应用程序架构的许多其他主题的内容.我将根据MVC Web应用程序来构建这个框架,但问题是,我确定,更广泛.它是这样的:对域实体的遵守是否会在应用程序中产生刚性和低效率？
DDD方法对于管理应用程序的业务逻辑以及与利益相关者合作的方式非常有意义.但对我而言,它在多层应用程序的背景下崩溃了.也就是说,当一个视图需要一个实体的所有数据或甚至两个存储库都拥有它时,很少有场景.本身并没有坏,但这意味着我做了多个查询返回一堆属性,我不需要得到一些我做的.一旦完成,无关信息将被传递到视图,或者存在丢弃,合并和映射数据到DTO或视图模型的开销.我需要生成大量报告,问题似乎在那里放大了.每个都需要一个独特的切片或聚合信息,SQL可以做得很好,但存储库不能,因为他们期望返回完整的实体.老实说,这看起来很浪费,我不想在原则问题上砸数据库并产生不必要的网络流量.从这样的问题中 ,存储库层应该返回数据传输对象(DTO)吗？看来我不是唯一一个与这个问题斗争的人.那么它似乎施加的限制的答案是什么？
感谢新的和混乱的DDD-er.
这里真正的问题是什么？处理业务规则和查询数据是两个非常不同的问题.这种实现将我们引向CQRS - Command-Query Responsibility Segregation.那是什么？您只是不对两个任务使用相同的模型:域模型是关于行为,执行业务流程,处理命令.并且有一个单独的报告模型用于显示.通常,它可以包含每个视图的表.这些表只包含相关信息,因此您可以摆脱DTO,AutoMapper等.
这两个模型如何同步？它可以通过多种方式完成: