DDD - 如何实现高性能的存储库进行搜索 [英] DDD - How to implement high-performing repositories for searching

问题描述

我有一个关于DDD和存储库模式的问题。

I have a question regarding DDD and the repository pattern.

说我对顾客聚集根的客户信息库。在获取和放大器; Find方法返回完全填充骨料，其中包括像Address对象，等等都不错。但是，当用户搜索在UI客户，我只需要集合体的摘要 - 与汇总信息只是一个平面物体。

Say I have a Customer repository for the Customer aggregate root. The Get & Find methods return the fully populated aggregate, which includes objects like Address, etc. All good. But when the user is searching for a customer in the UI, I just require a 'summary' of the aggregate - just a flat object with summarised information.

我可以处理的一种方法是调用库中的查找方法，正常，然后在应用层中，映射每个客户聚集到CustomerSearchResult通过/ customerinfo DTO，并将它们发送回客户端。

One way I could deal with this is to call the find method on the repository as normal, and then in the application layer, map each customer aggregate to a CustomerSearchResult / CustomerInfo DTO, and send them back to the client.

但我的问题，这就是性能;每个客户聚集，可能需要多个查询来填充所有关联的。所以，如果我的搜索条件匹配的50家客户，这是对DB相当命中潜在的检索数据我还没有将需要。

But my problem with this is performance; each Customer aggregate may require multiple queries to populate all of the associations. So if my search criteria matched 50 customers, that's quite a hit on the DB for potentially retrieving data I'm not even going to need.

另一个问题是，我可能希望包括有关客户是客户的总根边界之外，例如做了最后一次订单的日期汇总数据。订购有它自己的聚合，从而获得客户的订单信息，我会打电话给OrderRepository，也降低了性能。

The other issue is that I may wish to include summarised data about the customer that is outside of the Customer's aggregate root boundary, such as the date of the last order made for example. Order has it's own aggregate and therefore to get the customer's order information I would have to call the OrderRepository, also degrading performance.

所以，现在我觉得我有两种选择：

So now I think I'm left with two options:

1. 添加一个额外的查找方法，它通过做一有效的查询返回这些汇总对象的列表中CustomerRepository。

1. Add an additional Find method to the CustomerRepository which returns a list of these summary objects by doing one efficient query.

创建内置只读CustomerInfoRepository一个目的，那只是有1所描述的查找方法。

Create a purpose built readonly CustomerInfoRepository, that just has the find method described in 1.

不过，这两种感觉我逆着DDD的原则。我的存储库继承自一个通用的基础：库其中T：IAggregateRoot。这些汇总信息对象不是一个聚集体，是一个不同类型的T，所以真的＃1违背了设计。

But both of these feel like I'm going against the principles of DDD. My repositories inherit from a generic base: Repository where T : IAggregateRoot. These summary info object are not an aggregates, and are of a different type to T, so really #1 goes against the design.

也许对于＃2我会创建一个抽象SearchRepository没有IAggregateRoot约束？

Perhaps for #2 I would create an abstract SearchRepository without the IAggregateRoot constraint?

有我的领域很多相似的场景。

There are many similar scenarios in my domain.

您将如何实现这个场景？

How would you implement this scenario?

谢谢， 戴夫

更新

阅读西奥的回答后，我想我会去与选项＃2并创建我的基础设施面向这些情况下的一个专门SearchRepository。应用层（WCF服务）可以调用这些存储库，只是填充总结的DTO，而不是直接将域名映射实体DTO的。

After reading Theo's answer, I think I will go with option #2 and create a specialised SearchRepository within my infrastructure geared towards these scenarios. The application layer (WCF services) can then call these repositories that just populate the summary DTOs directly rather than mapping domain entities to DTOs.

的更新2 **

Update 2 **

虽然我在一年前，我想我只需要添加，因为其目的是解决这一确切的问题发现CQRS，我问过这一点。乌迪大寒（http://www.udidahan.com/）和格雷格·杨（HTTP：//$c$cbetter.com/gregyoung/）已经写了很多关于它。如果你正在创建一个分布式应用与DDD，CQRS是给你的！

Although I asked this over a year ago I thought I'd just add that I've since discovered CQRS which is aimed at solving this exact problem. Udi Dahan (http://www.udidahan.com/) and Greg Young (http://codebetter.com/gregyoung/) have written a lot about it. If you are creating a distributed application with DDD, CQRS is for you!

推荐答案

我认为你只是想显示汇总信息。的汇总信息，这些位是没有实体或域模型的值对象。他们是唯一的信息，仅此而已。

I think that you only want to display summarized information. These bits of summarized information are no entities or value objects of the domain model. They are only information, nothing more.

这多少有点像显示报告信息。如果我处理这样的事情，我不会坚持到纯DDD方法。你的建议的选项都OK，因为它让你的工作做好。 DDD应该不会被视为教条。创造性思考。拧松了一下DDD。

It is something like showing reporting information. If I deal with such things, I would not stick to the pure DDD approach. Your suggested options are OK, because it's getting your job done. DDD should be not treated as dogma. Think outside the box. Loosen up a bit DDD.

但要知道，你只是模型显示的目的之外创造信息价值。因此，如果用户选择一个比特的信息，使与它的一些操作（这是在域模型中定义的），你需要提取的信息值的标识，拉出实体/值对象/总从档案库。

But be aware that you are just creating informational values outside the model for displaying purpose. So if a user selects one bit of information to make some operation with it (which is defined in the domain model), you need to extract the identifier from the informational values and pull out the entity/value object/aggregate from a repository.

我强烈推荐这个视频：埃里克·埃文斯：因为这本书我已经了解了DDD。如果你读过他的书，你确实应该看到整个视频。非常密切地关注于对时间30:00埃里克·埃文斯本人谈到聚集，指的是你现在有这个问题。

I strongly recommend this video: Eric Evans: What I've learned about DDD since the book. If you read his book, you really should see the whole video. Pay very close attention at about time 30:00 where Eric Evans himself talks about aggregates and refers to the problem you currently have.

这篇关于DDD - 如何实现高性能的存储库进行搜索的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！