Clean/Onion架构下应用层服务依赖臃肿的最优解决方案探讨

问题场景 #

在Clean/Onion架构中，应用层服务常出现依赖臃肿问题：服务类的构造函数注入了多个依赖，但其中部分方法仅用到少数几个依赖，冗余依赖仍被强制注入。比如以下示例代码：

public class UserService : IUserService
{
    private readonly IService1 _service1;
    private readonly IService2 _service2;
    private readonly IService3 _service3;
    private readonly IService4 _service4;
    private readonly IService5 _service5;

    public UserService(
        IService1 service1,
        IService2 service2,
        IService3 service3,
        IService4 service4,
        IService5 service5)
    {
        _service1 = service1;
        _service2 = service2;
        _service3 = service3;
        _service4 = service4;
        _service5 = service5;
    }

    public async Task<UserDto> GetUserAsync(int id)
    {
        _service3.Log($"Fetching user {id}");
        var user = await _service1.GetUserByIdAsync(id);
        return _service2.MapToDto(user);
    }

    public async Task<bool> AuthenticateAsync(string username, string password)
    {
        _service3.Log($"Authenticating {username}");
        var user = await _service1.GetUserByUsernameAsync(username);
        return await _service4.VerifyPasswordAsync(user, password);
    }
}

示例中UserService的两个方法仅用到部分依赖，IService5完全未被使用，其余依赖也仅在特定方法中生效，但所有依赖都被注入到了类中。这种情况无需更换架构，核心是服务职责划分不清晰导致的问题，以下是最优解决方案：

最优解决方案 #

1. 拆分服务，严格遵循单一职责原则

这是最符合Clean/Onion架构设计理念的方案：将原服务中不同职责的方法拆分到独立的服务类中，每个服务只注入自身必需的依赖。

比如将UserService拆分为两个服务：

• UserQueryService：负责用户查询相关逻辑，仅注入IService1、IService2、IService3
• UserAuthenticationService：负责用户认证相关逻辑，仅注入IService1、IService3、IService4

拆分后的代码示例：

// 用户查询服务
public class UserQueryService : IUserQueryService
{
    private readonly IService1 _service1;
    private readonly IService2 _service2;
    private readonly IService3 _service3;

    public UserQueryService(IService1 service1, IService2 service2, IService3 service3)
    {
        _service1 = service1;
        _service2 = service2;
        _service3 = service3;
    }

    public async Task<UserDto> GetUserAsync(int id)
    {
        _service3.Log($"Fetching user {id}");
        var user = await _service1.GetUserByIdAsync(id);
        return _service2.MapToDto(user);
    }
}

// 用户认证服务
public class UserAuthenticationService : IUserAuthenticationService
{
    private readonly IService1 _service1;
    private readonly IService3 _service3;
    private readonly IService4 _service4;

    public UserAuthenticationService(IService1 service1, IService3 service3, IService4 service4)
    {
        _service1 = service1;
        _service3 = service3;
        _service4 = service4;
    }

    public async Task<bool> AuthenticateAsync(string username, string password)
    {
        _service3.Log($"Authenticating {username}");
        var user = await _service1.GetUserByUsernameAsync(username);
        return await _service4.VerifyPasswordAsync(user, password);
    }
}

拆分后每个服务的依赖都是必要的，完全消除冗余，同时契合Clean/Onion架构“关注点分离”的核心思想。

2. 移除完全未使用的依赖

先排查是否存在完全未被任何方法使用的依赖（比如示例中的IService5），这类依赖直接从构造函数和字段中移除即可，无需保留。

3. 临时过渡：按需延迟注入（不推荐长期使用）

如果暂时无法拆分服务，可以采用延迟注入的方式，即不在构造函数中注入所有依赖，而是在需要使用时从依赖注入容器中获取。比如通过IServiceProvider按需获取依赖：

public class UserService : IUserService
{
    private readonly IServiceProvider _serviceProvider;

    public UserService(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task<UserDto> GetUserAsync(int id)
    {
        var service3 = _serviceProvider.GetRequiredService<IService3>();
        var service1 = _serviceProvider.GetRequiredService<IService1>();
        var service2 = _serviceProvider.GetRequiredService<IService2>();
        
        service3.Log($"Fetching user {id}");
        var user = await service1.GetUserByIdAsync(id);
        return service2.MapToDto(user);
    }

    // 认证方法同理
}

注意：这种方式会隐藏服务的真实依赖，降低代码可读性和可测试性，仅适合作为短期过渡方案，长期仍需拆分服务。

总结 #

不需要更换Clean/Onion架构，该问题本质是服务违反了单一职责原则。拆分服务是最优解，既符合架构设计思想，又能彻底解决依赖臃肿问题。

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