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

Posted 2023-02-15

【中文标题】Nestjs 依赖注入和 DDD / 清洁架构

【英文标题】：Nestjs Dependency Injection and DDD / Clean Architecture

【发布时间】：2019-03-28 20:54:57

【问题描述】：

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

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

@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，但是遵循干净架构的原则，我不想为刚才的实现而烦恼，所以我为它写了一个接口：

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、干净的架构/DDD 和 Typescript），所以我在这里可能完全错了。

谢谢

【问题讨论】：

使用抽象类（+无默认功能）而不是接口（+字符串提供者）有什么好处？或相反。

【参考方案1】：

导出一个符号或字符串以及同名的接口

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
  

【参考方案2】：

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

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

// 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
  )

虽然比较冗长，但可以安全地从同名的不同模块导入多个服务。

【参考方案3】：

您确实可以使用接口，以及抽象类。一个打字稿功能是从类（保存在 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,
;

【讨论】：

是的，您只需要实施即可。

使用抽象类（+无默认功能）优于接口（+字符串提供者）有什么好处？或相反。

在这种情况下，您将需要使用抽象类将其（因此引用 DI）保留在 JS 世界中，因为接口根本不会被转译

【参考方案4】：

由于语言限制/功能(see structural vs nominal typing)，无法resolve dependency by the interface in NestJS。

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

例子：

// *** 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();
  

您也可以使用抽象类而不是接口，或者为接口和实现类指定一个相似的名称（并就地使用别名）。

是的，与 C#/Java 相比，这可能看起来像是一个肮脏的 hack。请记住，接口只是设计时的。在我的示例中，AppServiceMock 和 AppService 甚至没有继承自接口或抽象/基类（在现实世界中，它们当然应该），只要它们实现方法 root(): string，一切都会正常工作。

引用the NestJS docs on this topic:

通知

我们使用了 ConfigService 类而不是自定义令牌，因此我们覆盖了默认实现。