在我的基础结构层中，我为 Azure 搜索查询服务创建了一个项目，该服务实现了(我自己的(ISearchQueryService 接口。
项目中还有一个索引模型，该模型使用各种特定于 Azure 搜索的属性进行标记。
两者都依赖于 Azure 搜索 SDK。
在项目中，我还为 Azure 搜索配置(从 appsettings.json 读取(添加了一个模型，并将其注入到服务构造函数中。它具有特定于 Azure 搜索的属性值，例如 Azure 服务密钥。
由我的服务实现的 ISearchService 方法允许使用 Azure 搜索 SDK 中的类搜索索引。后者采用参数，例如具有字段名称/值的 ODATA 筛选器表达式和用于排序的字段名称列表。
我从应用程序层中的控制器服务调用 ISearchQueryService 方法。
我想使 ISearchQueryService 方法尽可能通用，以便我可以将参数值传递给服务，如下所示：
var departurePointSearchQueryDto = new DeparturePointSearchQueryDto
{
Filter = $"{nameof(IndexedDeparturePoint.TransitType)} eq 0",
OrderByFieldNames = new List<string>() { $"{nameof(IndexedDeparturePoint.DeparturePointName)}" }
};
我使用"nameof"来获取索引字段名称的编译时检查，但这意味着我的控制器服务现在直接引用 Azure 搜索查询项目。
我不确定这是否是一个问题，因为索引模型、配置模型和 ISearchQueryService 方法签名高度特定于 Azure 搜索。切换到另一个搜索提供程序意味着无论如何它们都需要重写 - 没有简单的方法可以将一个实现交换为另一个实现。
问。在此基础上，紧密耦合是否合理？如果没有，我应该考虑什么？
感谢@Nkosi建议">理想情况下，您希望使代码尽可能解耦，但有时现实世界胜过建议的做法" - 请参阅评论。
但是，为了解决问题中描述的紧密耦合，我在域层中创建了一个 IIndexedDeparturePoint。IndexedDeparturePoint 实现了 IIndexedDeparturePoint，我可以在运算符的名称中引用 IIndexedDeparturePoint。
我还在域层中移动了配置类，因此我尽可能多地删除了耦合。