Почему Clean Architecture не ускоряет внедрение новых фич, а скорее замедляет его на старте?

Почему Clean Architecture замедляет старт?

Clean Architecture, предложенная Робертом Мартином, предполагает строгое разделение кода на слои: сущности, use cases, адаптеры и фреймворки. Каждый слой зависит только от внутренних слоёв, а зависимости направлены внутрь. Это требует создания интерфейсов и абстракций для каждой внешней зависимости (базы данных, UI, API).

На старте проекта, когда требования ещё нестабильны, а функциональность минимальна, написание всех этих слоёв занимает больше времени, чем простое решение "в лоб". Например, для простого CRUD-приложения нужно создать репозиторий, use case, DTO и мапперы, вместо прямого вызова ORM из контроллера.

Пример кода

// Без Clean Architecture (быстро на старте)
router.get('/users/:id', async (req, res) => {
  const user = await db.users.findById(req.params.id);
  res.json(user);
});

// С Clean Architecture (медленнее на старте)
// UserController -> GetUserUseCase -> UserRepositoryInterface -> UserRepositoryImpl
class GetUserUseCase {
  constructor(userRepo) { this.userRepo = userRepo; }
  async execute(id) {
    const user = await this.userRepo.findById(id);
    return new UserDTO(user);
  }
}

Когда это оправдано?

Clean Architecture окупается, когда проект растёт: появляются новые источники данных, меняются фреймворки или требуется тестирование. Изоляция бизнес-логики позволяет заменять внешние компоненты без переписывания ядра. Для небольших проектов или прототипов такая архитектура избыточна.

Вывод: Clean Architecture замедляет старт из-за дополнительных абстракций, но обеспечивает гибкость и поддерживаемость в долгосрочной перспективе. Её стоит применять в крупных проектах с длительным жизненным циклом.