DDD洋葱架构下跨多层传递过滤器的最优实现方案咨询

现有方案评估 #

你的现有实现基本符合洋葱架构的分层隔离原则，但存在一个明显的冗余点：表现层的Index方法里，你将LogRabbitMQFilters类型的入参又映射为同类型的LogRabbitMQFilters对象，这步操作完全没有必要，可以直接删除，把入参的filters直接传给_iELKService.GetLog即可。

如果你的团队分层规范要求各层只能依赖自身定义的模型，修正冗余后的方案是合规的，尤其适合过滤器字段在各层需要做不同适配的场景（比如表现层的入参格式和持久层需要的查询参数格式差异较大）。但如果过滤器字段在各层完全对齐，两次映射会增加不必要的性能开销和维护成本。

可选的其他实现方案 #

1. 公共过滤器模型方案 #

如果你的过滤器字段在各层没有差异，不需要做任何格式适配，可以把过滤器类定义提取到应用层的公共契约模块中，表现层、应用层、持久层直接复用同一个过滤器类，完全省略两次映射操作，代码更简洁、维护成本更低，适合过滤逻辑简单、字段变化频率低的场景。

2. 规约模式方案 #

规约模式非常适合复杂过滤场景，如果你满足以下任意一个条件，就可以考虑使用：

• 过滤逻辑复杂，存在多条件动态组合的需求
• 同一段过滤规则需要在多个业务场景复用
• 希望把过滤规则的定义和持久层的查询实现完全解耦

实现思路：

• 在领域层/应用层定义通用的规约接口，每个具体的过滤规则封装为独立的规约实现类（比如LogLevelMatchSpecification、CreateTimeRangeSpecification）
• 应用层接收表现层的过滤器参数后，动态组合需要的规约对象集合
• 把组合后的规约集合传给持久层，持久层负责把规约翻译成对应存储的查询语句（比如ELK的Query DSL、关系型数据库的SQL条件）

这个方案的优势是过滤规则全部收拢在业务层，持久层不需要关心业务过滤逻辑，新增过滤条件只需要新增规约类，不需要修改各层的过滤器模型，扩展性非常强。

选型建议 #

• 过滤逻辑简单、字段稳定：选公共过滤器模型方案，代码最简洁
• 过滤逻辑复杂、多场景复用过滤规则：选规约模式，可维护性更高
• 分层规范要求严格、各层模型必须隔离：保留现有方案，删掉冗余的同类型映射即可

内容的提问来源于stack exchange，提问作者Julien Martin