返回原始类型的数据库调用应置于何处？应由应用服务还是领域服务调用？

先明确：你提到的三类查询可以分成领域相关和应用支撑两种，分别对应不同的实现位置和调用方，结合EF/Hibernate这类ORM的场景，具体建议如下：

1. 业务规则检查类查询（属于领域逻辑） #

比如检查数据库中某条件是否满足以执行业务流程，这类是领域逻辑的一部分：

• 直接在领域层的Repository接口里新增方法，比如bool IsSkuAlreadyUsed(string sku)、bool IsOrderInValidState(Guid orderId)。
• 调用方就是Domain Service，因为业务逻辑的决策依赖这些查询结果，Domain Service本身就该掌控这类判断。
• ORM实现时，在基础设施层的Repository实现类里，用Linq/HQL写对应的查询直接返回布尔值、枚举这类简单类型——别纠结Repository只能返回实体，只要是服务于领域逻辑的查询，都可以放在这里。

2. 应用层支撑类查询（非核心领域逻辑） #

比如填充下拉列表的表值、根据用户输入获取Domain Service所需的参数数据，这类是为了支撑UI或应用流程，不属于核心业务逻辑：

• 不用单独搞DAO层，直接在基础设施层写独立的查询类，比如CategoryLookupQueries、CustomerFilterQueries，直接依赖ORM的DbContext/Session，写针对性的查询方法，返回DTO、枚举列表、ID集合这类轻量化数据。
• 调用方是Application Layer：比如UI控制器直接调用查询类拿下拉数据，或者Application Service先调用它拿到参数，再传给Domain Service处理。
• 和Repository完全独立：Repository专注于领域实体的生命周期管理（增删改查完整实体），这类查询类专门处理特定场景的轻量化数据获取，避免把Repository搞成啥都有的大杂烩。

为啥不用单独的DAO层？ #

用EF/Hibernate这类ORM时，ORM本身已经帮你做了传统DAO的大部分工作，再单独搞DAO层纯属冗余：

• Repository的实现本来就依赖ORM，直接在Repository里扩展领域相关查询更简洁。
• 应用层的查询直接用ORM写针对性方法，比通过DAO中转更高效，也更贴合具体的UI需求。

最后总结下：

• 领域相关的查询（业务规则检查）：归Repository管，Domain Service调用。
• 应用支撑类查询：写独立查询类，Application Layer直接调用。
• 没必要单独搞DAO层，ORM直接当数据访问基础就行。

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