Два варианта. Один выбор.

Допустим, у нас есть задача реализовать user story:

Как пользователь платформы, я хочу начать урок, чтобы продолжить обучение и потратить накопленные токены.

Наивная реализация на TypeScript + NestJS могла бы выглядеть как-то так:

async startLesson(userId: string, lessonId: string) {
    const user = await this.userRepository.findById(userId)
    const lesson = await this.lessonRepository.findById(lessonId)
    
    const subscription = await this.subscriptionRepository.findActiveByUser(userId)
    if (!subscription || subscription.expiresAt < new Date()) {
        throw new Error("No active subscription")
    }
    
    if (user.tokens < lesson.tokensCost) {
        throw new Error("Not enough tokens")
    }
    
    await this.userRepository.update(userId, { tokens: user.tokens - lesson.tokensCost })
    await this.progressRepository.create({ userId, lessonId, status: "started", startedAt: new Date() })
    await this.analyticsService.track("lesson_started", { userId, lessonId })
}

Код рабочий и простой. Но насколько он хорош? Остановитесь на секунду и назовите 2-3 потенциальные проблемы этого кода. Я нашел сразу пять:

- Проверка подписки здесь, хотя должна быть в отдельном слое доступа.
- Списание токенов не атомарное - между проверкой и обновлением токены может списать другой запрос.
- Нет транзакции - если сервер упал между update и create, токены списались, а прогресс не создался.
- Аналитика блокирует основной поток.
- Нет уникального индекса на прогресс.

Учитывая эти моменты, можно сделать более надёжную реализацию:

async startLesson(userId: string, lessonId: string) {
    return this.unitOfWork.execute(async (uow) => {
        const user = await uow.users.findById(userId)
        const lesson = await uow.lessons.findById(lessonId)
        
        if (!user || !lesson) {
            throw new Error("User or lesson not found")
        }
        
        const accessResult = await this.accessService.checkAccess(user, lesson)
        if (!accessResult.allowed) {
            throw new Error(accessResult.reason)
        }
        
        const updateResult = await uow.users.updateOne(
            { _id: userId, tokens: { $gte: lesson.tokensCost } },
            { $inc: { tokens: -lesson.tokensCost } }
        )
        
        if (updateResult.modifiedCount === 0) {
            throw new Error("Not enough tokens")
        }
        
        return await uow.progress.create({
            userId,
            lessonId,
            status: "started",
            startedAt: new Date()
        })
    })
}

Код стал сложнее и надёжнее: транзакция, атомарность, разделение ответственности.

Но суть в том, что для небольшого проекта с десятком активных пользователей эта сложность чаще всего не нужна. Вероятность race condition стремится к нулю. Если транзакция зависнет - техподдержка поправит токены за пять минут, а вы потратили кучу времени на Unit of Work.

Стал ли код лучше? И да, и нет. Первый вариант по-прежнему остается самым читаемым, понятным и простым. Но на перспективу иметь разделение обязанностей и четкие границы между слоями - это очевидный плюс.

Получается два разных варианта, оба рабочие. Но какой из них подойдет в конкретной ситуации - это решение, которое должен принять разработчик. Реальное программирование - это всегда компромисс между надёжностью, универсальностью и простотой.

Важно помнить, что как программисты, мы всегда можем объяснить, какие проблемы есть в коде, какие опасности они создают. Но насколько эти "проблемы" реальны - сказать сложно. И никто не знает, какой выбор нужно сделать. Знаю только, что через год-два открою этот код и не вспомню, почему выбрал именно так. И, скорее всего, нужно будет объяснять новые проблемы и переписывать... Опять.