Nestjs 종속성 주입 및 DDD / Clean Architecture

Nestjs 종속성 주입 및 DDD / Clean Architecture

청정 아키텍처 구조를 구현하기 위해 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그래서 토큰이 달라서 네스트가 의존성을 해결할 수 없는 것으로 알고 있습니다.

이에 대한 유일한 해결책은 사용자 지정 공급자를 사용하여 토큰을 수동으로 설정하는 것입니다.

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

그리고 수정합니다.ProfileDomainEntity사용할 토큰을 지정하여@Inject:

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

이 방법이 모든 종속성을 처리하는 데 사용할 수 있는 합리적인 방법입니까? 아니면 제가 완전히 탈선한 것입니까?더 좋은 해결책이 없을까요?저는 이러한 모든 것(NestJs, 청정 아키텍처/DDD 및 유형 스크립트)에 대해 상당히 생소한 사람이기 때문에 여기서는 완전히 틀릴 수 있습니다.

감사해요.

언어 제한/기능 때문에 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 비이더것해러킹보처럼일수있습다니운은교하면와▁yes,▁c있▁might▁look습다▁comparing예니.인터페이스는 디자인 타임에 불과합니다. 제예서는에,,AppServiceMock그리고.AppService 클래스 함, " 인베이스실/, 동법을구는것하한이모현든당히는제로연이▁▁are▁as▁(▁work▁will▁they▁인▁as다▁long▁every▁implement"를 구현하는 한 모든 것이 작동할 것입니다.root(): string.

이 주제에 대한 NestJS 문서의 인용:

알려드립니다

사용자 지정 토큰 대신 ConfigService 클래스를 사용했기 때문에 기본 구현을 재정의했습니다.

같은 이름의 인터페이스와 함께 기호 또는 문자열 내보내기

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
  }
}

인터페이스를 사용할 수 있습니다. 추상적인 클래스를 사용할 수 있습니다.한 가지 유형 스크립트 기능은 클래스(JS 월드에 유지됨)에서 인터페이스를 추론하는 것이므로, 이와 같은 기능이 작동합니다.

아이푸.츠

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

풋스

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

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

여러 모듈 간의 명명 충돌을 방지하는 데 도움이 되는 다른 접근 방식을 사용합니다.

구현 세부 정보를 숨기기 위해 사용자 지정 데코레이터와 함께 문자열 토큰을 사용합니다.

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

더 자세한 내용이지만 동일한 이름을 가진 여러 모듈에서 여러 서비스를 안전하게 가져올 수 있습니다.

참고로 다음과 같습니다.

DDD/Clean 아키텍처를 따르는 경우 도메인 엔티티에서 리포지토리에 액세스하면 안 됩니다.

사용 사례 클래스 또는 도메인 서비스는 리포지토리를 사용하여 도메인 엔티티를 가져온 다음 이에 대해 작업을 수행하고 동일한 사용 사례/도메인 서비스가 완료되면 도메인 엔티티를 저장합니다.

도메인 엔티티는 아키텍처 다이어그램의 중앙에 위치하며 다른 항목에 의존해서는 안 됩니다.

언급URL : https://stackoverflow.com/questions/52969037/nestjs-dependency-injection-and-ddd-clean-architecture