Nestjs 依赖注入和 DDD / 清洁架构

Question

我正在通过尝试实现一个干净的架构结构来试验 Nestjs，我想验证我的解决方案，因为我不确定我是否理解最好的方法。请注意，该示例几乎是伪代码，很多类型缺失或通用，因为它们不是讨论的重点。

从我的域逻辑开始，我可能想在 class 中实现它，如下所示：

@Injectable()
export class ProfileDomainEntity {
  async addAge(profileId: string, age: number): Promise<void> {
    const profile = await this.profilesRepository.getOne(profileId)
    profile.age = age
    await this.profilesRepository.updateOne(profileId, profile)
  }
}

这里需要访问profileRepository，但是遵循clean architecture的原则，不想被刚才的实现打扰所以写了一个接口：

interface IProfilesRepository {
  getOne (profileId: string): object
  updateOne (profileId: string, profile: object): bool
}

然后我在 ProfileDomainEntity 构造函数中注入依赖项，并确保它遵循预期的接口：

export class ProfileDomainEntity {
  constructor(
    private readonly profilesRepository: IProfilesRepository
  ){}

  async addAge(profileId: string, age: number): Promise<void> {
    const profile = await this.profilesRepository.getOne(profileId)
    profile.age = age

    await this.profilesRepository.updateOne(profileId, profile)
  }
}

然后我创建了一个简单的内存实现，让我运行代码：

class ProfilesRepository implements IProfileRepository {
  private profiles = {}

  getOne(profileId: string) {
    return Promise.resolve(this.profiles[profileId])
  }

  updateOne(profileId: string, profile: object) {
    this.profiles[profileId] = profile
    return Promise.resolve(true)
  }
}

现在是时候使用模块将所有东西连接在一起了：

@Module({
  providers: [
    ProfileDomainEntity,
    ProfilesRepository
  ]
})
export class ProfilesModule {}

这里的问题是显然 ProfileRepository 实现了 IProfilesRepository 但它不是 IProfilesRepository 因此，据我所知，令牌不同，Nest 无法解析依赖关系。

我找到的唯一解决方案是使用自定义提供程序来手动设置令牌：

@Module({
  providers: [
    ProfileDomainEntity,
    {
      provide: 'IProfilesRepository',
      useClass: ProfilesRepository
    }
  ]
})
export class ProfilesModule {}

并通过指定要与 @Inject 一起使用的令牌来修改 ProfileDomainEntity:

export class ProfileDomainEntity {
  constructor(
    @Inject('IProfilesRepository') private readonly profilesRepository: IProfilesRepository
  ){}
}

这是一种处理我所有依赖关系的合理方法，还是我完全偏离了轨道？有没有更好的解决办法？我对所有这些东西都是新手（NestJs，clean architecture/DDD 和 Typescript）所以我在这里可能完全错了。

谢谢

Answer 1

无法resolve dependency by the interface in NestJS due to the language limitations/features (see structural vs nominal typing)。

并且，如果您使用接口来定义（类型）依赖项，则必须使用字符串标记。但是，你也可以使用 class 本身，或者它的名字作为字符串文字，所以你不需要在注入过程中提及它，比如依赖的构造函数。

示例：

// *** app.module.ts ***
import { Module } from '@nestjs/common';
import { AppController } from './app.controller';
import { AppService } from './app.service';
import { AppServiceMock } from './app.service.mock';

process.env.NODE_ENV = 'test'; // or 'development'

const appServiceProvider = {
  provide: AppService, // or string token 'AppService'
  useClass: process.env.NODE_ENV === 'test' ? AppServiceMock : AppService,
};

@Module({
  imports: [],
  controllers: [AppController],
  providers: [appServiceProvider],
})
export class AppModule {}

// *** app.controller.ts ***
import { Get, Controller } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  constructor(private readonly appService: AppService) {}

  @Get()
  root(): string {
    return this.appService.root();
  }
}

您也可以使用抽象 class 代替接口，或者为接口和实现提供相似的名称 class（并就地使用别名）。

是的，与 C#/Java 相比，这可能看起来像是一个肮脏的 hack。请记住，接口只是设计时的。在我的示例中，AppServiceMock 和 AppService 甚至都不是从接口继承的，也不是 abstract/base class （在现实世界中，他们当然应该），只要他们实现方法 root(): string.

引自the NestJS docs on this topic：

NOTICE

Instead of a custom token, we have used the ConfigService class, and therefore we have overridden the default implementation.

Answer 2

你确实可以使用接口，抽象得很好类。打字稿的一项功能是从类推断接口（保存在 JS 世界中），所以像这样的东西会起作用

IFoo.ts

export abstract class IFoo {
    public abstract bar: string;
}

Foo.ts

export class Foo 
    extends IFoo
    implement IFoo
{
    public bar: string
    constructor(init: Partial<IFoo>) {
        Object.assign(this, init);
    }
}

const appServiceProvider = {
  provide: IFoo,
  useClass: Foo,
};

Answer 3

我使用了一种不同的方法来帮助防止跨多个模块的命名冲突。

我使用字符串标记和自定义装饰器来隐藏实现细节：

// injectors.ts
export const InjectProfilesRepository = Inject('PROFILES/PROFILE_REPOSITORY');

// profiles.module.ts
@Module({
  providers: [
    ProfileDomainEntity,
    {
      provide: 'PROFILES/PROFILE_REPOSITORY',
      useClass: ProfilesRepository
    }
  ]
})
export class ProfilesModule {}

// profile-domain.entity.ts
export class ProfileDomainEntity {
  constructor(
    @InjectProfilesRepository private readonly profilesRepository: IProfilesRepository
  ){}
}

它更冗长，但可以从具有相同名称的不同模块安全地导入多个服务。

Answer 4

导出符号或字符串以及同名的界面

export interface IService {
  get(): Promise<string>  
}

export const IService = Symbol("IService");

现在您基本上可以使用 IService 作为接口和依赖标记

import { IService } from '../interfaces/service';

@Injectable()
export class ServiceImplementation implements IService { // Used as an interface
  get(): Promise<string> {
    return Promise.resolve(`Hello World`);
  }
}

import { IService } from './interfaces/service';
import { ServiceImplementation} from './impl/service';
...

@Module({
  imports: [],
  controllers: [AppController],
  providers: [{
    provide: IService, // Used as a symbol
    useClass: ServiceImplementation
  }],
})
export class AppModule {}

import { IService } from '../interfaces/service';

@Controller()
export class AppController {
  // Used both as interface and symbol
  constructor(@Inject(IService) private readonly service: IService) {}

  @Get()
  index(): Promise<string> {
    return this.service.get(); // returns Hello World
  }
}

Answer 5

旁注：

如果您遵循 DDD/Clean 体系结构，则不应从域实体访问存储库。

用例 class 或域服务将使用存储库获取域实体，然后您对其进行操作，当您完成相同的 usecase/domain 服务时，将存储域实体。

域实体位于体系结构图的中心，它不应该依赖于任何其他东西。

Nestjs 依赖注入和 DDD / 清洁架构

Nestjs Dependency Injection and DDD / Clean Architecture

domain-driven-design

dependency-injection

typescript

clean-architecture

nestjs