DDD应用层内部服务调用：避免过度DTO映射的方案咨询

问题背景 #

我采用DDD架构开发应用，分为Domain（领域层）、Application（应用层）和Infrastructure（基础设施层）：

• 领域层：包含带业务逻辑的实体及领域服务
• 应用层：设有名为Managers的高层服务，接收DTO，映射为领域对象调用验证器、业务逻辑，完成后再映射回DTO返回
• 基础设施层：依赖应用层的Managers

当前遇到的核心问题：应用层内Manager间调用时，因输入输出均为DTO，产生大量冗余映射代码，流程如下：

1. 将输入DTO映射为领域对象
2. 以DTO调用另一个Manager
3. 接收DTO结果
4. 将结果DTO映射回领域对象
5. 将最终结果映射为DTO返回给基础设施层

尝试方案的困境：封装直接使用领域实体的内部服务注入到Managers，希望Manager仅对外暴露面向基础设施层的公开方法，但遇到依赖注入报错：
"Inconsistent accessibility: parameter type 'Interface' is less accessible than method 'Constructor'"
若将接口设为公开，又会暴露给基础设施层，违背仅让其依赖Managers的设计。

常规解决方案 #

1. 利用程序集内部可见性+内部DI配置 #

以C#为例，可通过internal修饰符限定内部服务的可见范围：

• 定义internal接口和internal实现类，仅在应用层程序集内部可见
• 在应用层内创建内部DI配置类（同样标记为internal），完成内部接口与实现类的绑定
• Managers的构造函数保持public供外部注入，但内部服务的实例由应用层内部DI配置提供，避免外部层感知到内部接口的存在

2. 应用层内拆分内部子层 #

在应用层中划分Application.Internal子模块，该模块下的所有接口、服务类都标记为仅对应用层内部可见（如C#的internal、Java的包访问权限）：

• Managers作为应用层对外的唯一入口，依赖该内部子层的服务
• 基础设施层只能访问Managers，无法触及内部子层的任何内容，既保留依赖注入能力，又严格隔离层边界

3. 接受有限冗余并优化映射效率 #

在DDD实践中，有限的映射冗余是普遍接受的，因为它能清晰维护层边界，避免领域实体暴露给外部层。可通过以下方式降低冗余成本：

• 使用AutoMapper等工具自动生成映射代码，消除手动编写的样板逻辑
• 封装通用映射工具类，统一处理DTO与领域对象的转换逻辑

应用层服务间是否应使用DTO？ #

应用层内部服务间（包括Manager调用其他Manager、内部服务互调）不建议使用DTO：

• DTO的核心作用是跨层数据传输，应用层内部属于同一上下文，直接传递领域实体/值对象更高效，也能避免冗余映射
• 正确的设计应该是：Managers作为应用层对外门面，仅对外部（基础设施层、API层等）暴露DTO接口；应用层内部的共享逻辑通过内部服务封装，内部调用直接使用领域对象，避免Manager之间直接调用

内容的提问来源于stack exchange，提问作者M. Ozn