🧠 Простая сила чистого кода: философия “Функциональное ядро, императивная оболочка” от Google

Компания Google снова напоминает разработчикам о старом, но вечно актуальном принципе — разделяй и властвуй. На этот раз в контексте архитектуры кода: функциональное ядро и императивная оболочка.
На первый взгляд — звучит академично. Но на практике это один из тех приёмов, который делает код понятным, тестируемым и долговечным.

⚙️ Что это значит

Google Testing Blog предлагает делить код на две части:

💡 Функциональное ядро (Functional Core) —
чистые функции без побочных эффектов. Они работают только с переданными данными и ничего не меняют вне своей области видимости. Ни БД, ни сеть, ни глобальные переменные — только логика и данные.

⚡️ Императивная оболочка (Imperative Shell) —
всё, что связано с вводом-выводом, API, базами данных, файлами, пользователями. Она “оборачивает” ядро, вызывая его функции и управляя взаимодействием с внешним миром.

💌 Пример из жизни: рассылка писем

Рассмотрим пример из блога Google. Был код, который отправлял письма о просроченной подписке:

// Плохой пример
function sendUserExpiryEmail() {
for (const user of db.getUsers()) {
if (user.subscriptionEndDate > Date.now()) continue;
if (user.isFreeTrial) continue;
email.send(user.email, "Your account has expired " + user.name + ".");
}
}

Здесь смешано всё: бизнес-логика, фильтрация пользователей и побочные эффекты (запрос к БД, отправка писем).
Тестировать это невозможно без моков. Менять — боль.

✅ Вариант с разделением:

// Функциональное ядро
function getExpiredUsers(users, cutoff) {
return users.filter(u => u.subscriptionEndDate <= cutoff && !u.isFreeTrial);
}
function generateExpiryEmails(users) {
return users.map(u => [u.email, `Your account has expired ${u.name}.`]);
}

// Императивная оболочка
email.bulkSend(generateExpiryEmails(getExpiredUsers(db.getUsers(), Date.now())));

Теперь ядро можно протестировать изолированно, без БД и без SMTP-сервера. А если завтра вы решите заменить email-сервис на Kafka или push-уведомления — просто перепишете оболочку, не трогая бизнес-логику.

🧩 Почему это важно

• 🧪 Тестируемость — чистые функции легко покрыть юнит-тестами без моков и сложных зависимостей.
• 🔁 Повторное использование — ядро можно применять в CLI-инструменте, веб-сервисе, даже в серверлес-функции.
• 🧱 Гибкость архитектуры — оболочку можно заменить: из REST сделать gRPC, из SMTP перейти на SQS.
• 🚀 Простота эволюции — новые типы уведомлений добавляются созданием одной новой функции, а не правками в десятках мест.

🔍 Технические детали

С архитектурной точки зрения, паттерн “Функциональное ядро, императивная оболочка” близок к идеям Гексагональная архитектура и Чистая архитектура:

• 💾 Ядро изолировано от инфраструктуры.
• 🧩 Оболочка — адаптер, который знает, как применить логику.
• 🧠 Зависимости направлены внутрь — от внешнего слоя к внутреннему.

Это упрощает внедрение зависимостей (dependency injection) и снижает когнитивную нагрузку на разработчика.

💬 Мой взгляд

Мне кажется, этот подход особенно важен в эпоху LLM-инструментов и автогенерации кода. Когда часть логики пишет ИИ, важно, чтобы система оставалась человеко-понятной и детерминированной.
Функциональное ядро обеспечивает именно это — прозрачность, повторяемость, контроль.

Я применяю такой подход в своих проектах на Python и Go:
в микросервисах ядро реализовано как чистые функции (бизнес-правила),
а оболочка — как слой FastAPI, Kafka-воркеры или CLI-обработчики.
Так тесты запускаются мгновенно, а бизнес-логика не зависит от сетевого стека.

🔗 Источник

• 🧾 Оригинальная статья Google Testing Blog (Arham Jain, 2025):
  Simplify Your Code: Functional Core, Imperative Shell