我使用 CQRS 瘦读取层为 UI 提供非规范化列表/报告数据。
在我的应用程序的某些部分，我想提供一个搜索框，以便用户可以过滤数据。
Lucene.NET 是我目前首选的全文搜索引擎，因为我之前已经实现过它并且对它非常满意。
但是，事物的搜索方面在哪里适合 CQRS？
我看到两个选项，但可能还有更多。
1] 我的控制器可以将搜索字符串传递给搜索层 (Lucene.NET)，它返回一个 ID 列表，然后我可以将其传递给 CQRS 读取层。读取层将获取这些 ID 并将它们组装成 WHERE ID IN (1,2,3) 子句，最终将 DataTable 或 IEnumerable 返回给控制器。
List<int> ids = searchLayer.SearchCustomers("searchString");
result = readLayer.GetCustomers(ids);
2] 我的薄读取层可以直接将搜索编码到其中，所以我只需调用
readLayer.GetListOfCustomers("search string", page, page1);
请记住，使用 CQRS 并不意味着您在应用程序的每个部分都使用它。将应用程序切成更小的组件允许使用各种有意义的架构原则和模式。全文搜索 API 可能是这些组件之一。
在不知道您的应用程序的所有细节的情况下，我会倾向于从您的控制器到您的搜索层的单个入口点（上面的选项＃2）。我认为您的控制器不应该知道它需要调用第 1 层进行启用全文搜索，而调用第 2 层进行常规WHERE子句类型搜索。
我假设您将有两个不同的“上下文”（例如SQLContext和LuceneContext），这些将是注入到您的ReadLayer. 然后，您的读取层逻辑应决定何时使用LuceneContext和何时使用SQLContext；您的控制器不会知道也不应该知道。
LuceneContext如果将来有令人信服的原因，您也可以MongoContext在控制器不知道或不必更改的情况下更换。
如果你对所有东西都使用接口（例如ISearchContext，由LuceneContextand实现MongoContext），那么换出上下文的唯一变化就是你的 IoC 容器的初始化/规则。
所以，使用选项#2，注入你的依赖项，让你的控制器通过你的读取层工作，你应该很高兴。希望这会有所帮助！