Каким должен быть репозиторий в сервисе — конкретной реализацией или абстракцией?

Почему абстракция, а не реализация

В сервисном слое репозиторий должен быть представлен интерфейсом (абстракцией), а не конкретным классом. Это следует из принципа инверсии зависимостей (Dependency Inversion Principle) — модули верхнего уровня не должны зависеть от модулей нижнего уровня, оба должны зависеть от абстракций.

Преимущества подхода

• Сервис не привязан к конкретной базе данных или ORM
• Легко подменять реализацию для тестирования (mock-объекты)
• Упрощается миграция между хранилищами
• Код становится более гибким и переиспользуемым

Пример на TypeScript

// Абстракция (интерфейс)
interface UserRepository {
  findById(id: string): Promise<User | null>;
  save(user: User): Promise<void>;
}

// Конкретная реализация для PostgreSQL
class PostgresUserRepository implements UserRepository {
  async findById(id: string): Promise<User | null> {
    // SQL запрос к БД
  }
  async save(user: User): Promise<void> {
    // INSERT запрос
  }
}

// Сервис зависит от абстракции
class UserService {
  constructor(private repo: UserRepository) {}

  async getUser(id: string) {
    return this.repo.findById(id);
  }
}

Где применяется

Данный подход используется в большинстве современных фреймворков (Spring, NestJS, ASP.NET Core) и рекомендуется в DDD (Domain-Driven Design). Он особенно полезен в крупных проектах, где требуется тестирование и гибкость.

Вывод: Используйте абстракцию репозитория в сервисе всегда, когда возможна смена хранилища или нужна изоляция для тестов. Это делает архитектуру чище и устойчивее к изменениям.