Injectable как раз палит какие у тебя зависимости в конструкторе

++

потому если хочется чисто — нужно принять, что Services неста — это Application Services и не смешивать их с Domain Services

но опять же — это может быть жутким переусложнением на большинстве проектов, абстракции ради чистоты )

задача архитектора — соблюдать баланс

именно, нужно понимать ценность и профит в рамках требований.

cats-repository.ts:

export class CatsRepository extends AbstractCatsRepository {
  constructor(connection: AbstractConnection) {}
}


app.module.ts:

@Module({
  providers: [
    CatsRepository,
    {
      provide: AbstractConnection,
      useValue: ConcreteConnection,
    }
  ],
})
export class AppModule {}

в общем пока код выше не работает в nestjs (без `@Injectable`) нету смысла заморачиваться с abstract class

Ну и даже если пишешь не чисто — понимать риски, не делать это бездумно.

это другое

хотя да, если мы считаем, что слой один то и абстракции не нужны )

+

идеи были:
- добиться чистоты и не зависимости от nestjs
- писать меньше ручного создания объектов за счет DI nest’a

но nestjs проникает в логику (`@Injectable`) - не круто

чисто теоритически обычно все сервиса пишутся в спец. секцию providers в @Module

providers: [CatsRepository],

то есть nestjs о сервисах знает и он бы мог сам их конструкторы проверить (какие там зависимости), но видимо не все так просто.
Видимо обязательно декоратор нужен чтоб метаданные из ts получить по конструктору

Да, анализатор бежит по декораторам

хм а если так (наполовину руками)?

cats-service.ts:

export class CatsService {
  constructor(repository: ICatsRepository) {}
}


app.module.ts:

@Module({
  providers: [
    { provide: ‘ICatsRepository’, useFactory: () => new CatsRepository() },
    {
      provide: ‘CatsService’,
      useFactory: (repository: ICatsRepository) => new CatsService(repository),
      inject: [‘ICatsRepository’],
    }
  ],
})
export class AppModule {}

в таком подходе нам не нужна метадата, т.к. мы сами делаем new T() (но только в конфигурации DI !)
а за нас весь граф зависимостей сам резолвится будет
Но тут еще все можно ошибиться с порядком аргументов в inject (ts не чекает), возможно это честная плата за использования общего DI фрейморка и в тоже время отвязанную бизнес логику от него

P.S: Вместо строк можно использовать что-то другое например так (или Symbol ) :

{ provide: CatsRepository, useFactory: () => new CatsRepository() },

не стесняйтесь вбросить кто что думает

А в чём ещё раз минус зависимости от @injectable?

Если вопрос в замене фреймворка на другой - можно завернуть его в свой декоратор

У тебя проникает фреймворк со всей его логикой работы с зависимостями. И в тесты ты тоже тянешь фреймворк

Но декоратор вроде только добавляет метадату и все?