Чистые архитектуры и вакуум

Слоёная архитектура нынче почитается уже за "классическую". По крайней мере так говорят поклонники "чистой архитектуры" (clean architecture). Возникнув в эпоху перехода к клиент-серверным технологиям конца 1980-х - начала 1990-х, слоёная архитектура не меняла свои принципы, а только наращивала логические слои. В информационной системе концептуальных слоёв всегда три: хранение, обработка и представление. И хотя физических слоёв (tiers) может быть и меньше, вплоть до автономного приложения со встроенной СУБД, слоёв логических набирается обычно гораздо больше, каждый со своим развесистым API. Более подробное описание матрицы "слои-уровни" приведено в статье или книге

Слабое место "слоёной" архитектуры известно: изменения нижних слоёв производят тектонические сдвиги в вышестоящих, что ведёт к дестабилизации части системы и необходимости дополнительных усилий по устранению регрессии. Структурные изменения пытались решать генерацией рутинного кода слоёв из модели (MDA, MDD, пример software factory), но такой подход требует серьёзных навыков работы с абстракциями, а не беспрерывного и беспощадного кодирования в колесе спринтов.

Поэтому с конца 1990-х - начала 2000-х годов ведутся попытки "сотрясения основ" путём создания альтернативных подходов к проектированию информационных систем: "гексагональная", "луковая" и, наконец, "чистая" архитектуры. Основной смысл вышеназванных подходов вроде бы здравый: отделить модели предметной области (МПО) от любых деталей реализации и развертывания. Здесь я должен сделать культурологический отступ и процитировать старинный анекдот.

Биолога, физика и статистика попросили рассчитать, какая лошадь займет на скачках первое место в следующем году. Разошлись они, а через год собрались снова.
Статистик: Я просмотрел всю информацию о лошадях за последние 10 лет и вычислил, что первой станет лошадь Белая Бабочка.
Биолог: Я изучил всю генеалогию лошадей, принимающих участие в скачках, узнал о состоянии их здоровья и заключил, что конь Гиацинт придет первым.
Физик: Мне требуется миллион и еще 3 года, но я уже разработал модель сферического коня в вакууме!

Первое, что приходит на ум при виде предлагаемых архитектур, это именно модель сферического коня в вакууме.

Похоже, стремление отделить любые реалии окружения МПО сыграло злую шутку с проектировщиками. Прежде всего проблема проявляется в непонятном желании выслать базы данных на инфраструктурную периферию, словно какую-то файловую систему.

Действительно, существуют как минимум два равноценных подхода к описанию МПО, так называемые "objects first" и "data first" (другие варианты: "domain first" и "schema first"). Но подходов вроде "infrastructure first" или "services first" не может быть в принципе. Потому что объекты и данные уже существуют вне создаваемой программной системы, а сервисы вы придумываете для соответствующей сервис-ориентированной реализации. И, например, в событийной реализации или в архитектуре "ядро-модули" (фреймворк-плагины) сервисов может не быть совсем, тогда как данные (структуры, объекты) и функции (методы) их обработки присутствуют всегда.

Определение "программы -- это алгоритмы + структуры данных" неоспоримо и полвека спустя формулировки.

Концепция сферической МПО в вакууме прекрасно ложится на подход DDD. Не потому, что подход универсален, а потому что МПО перенесли в подходящий вакуум и подогнали по размерам прокрустова ложа методики.

Не так давно, сократив перемоткой видео до часа, я решил послушать за обедом "рекламу" DDD в контексте чистых архитектур. Несколько затянуто, хотелось бы пободрее и повеселее, на полчаса-час максимум. Но поскольку эти вопросы обсуждались лет 25 назад в fido7.su.oop, захотелось провести параллели.

• Пример приложения на Котлине, видимо, должен поразить всех, кто еще подумывает о чистоте архитектуры, тотальными впрыскиваниями интерфейсов. Однако, если для трех таблиц и пяти экранных форм нужно сооружать вот это вот всё, то что же нас ждет в действительно сложной многодоменной ERP?!
• DDD изначально заточен под имитационное моделирование, где объекты активны, обладают поведением, а о "персистентности" можно вообще не думать. "Энтерпрайз" -- это автоматизация информационных систем: сущности пассивны, но почти все долговременно хранимы, ими манипулируют люди через процессы. Получается почти 100% "анемичная модель" в терминах DDD. Но тогда, по идее, и подход должен был бы быть с другого конца (привет SADT и IDEF0), не правда ли? Да, ребята, объект "автомобиль" в системе симуляции дорожного движения -- это совсем не то, что объект "заказ на автомобиль" в системе продажи товаров.
• Говорить о том, что МПО представляет собой главную ценность в системе некорректно. Как правило, в информационной системе бизнеса главную ценность имеют данные. Именно их переносят из одной программной системы в другую при миграции. И не дай бог потерять что-то по дороге.
• Очевидное: все эти getByXXX работают только для простых CRUD-ов. Первый же dashboard с десятком панелей уровня "топ 10 заказов за 5 дней по товарам группы скоропортящихся среди клиентов с оборотом более 1М в месяц" снесет абстракцию к чертовой бабушке, как неадекватную.
• Рассуждения о СУБД, как об устройстве ввода-вывода, в котором, однако, нужно продублировать ограничения домена-МПО (sic!) несколько забавны. А если еще вспомнить, что уровень абстракции объектной и реляционной моделей примерно одинаков...

В целом, так же как совсем другие люди 25 лет назад, авторы снова подводят искушенного слушателя к неутешительному выводу: ООП в 1960-е годы появилось для решения задач имитационного моделирования, а промышленные СУБД в те же годы (а не в 1980-е, как авторы дезинформировали слушателя) -- для автоматизации ИС.

Серебряной пули нет, но есть ли в сферических архитектурах технологическое развитие по сравнению со слоёным пирогом из API? Вопрос остается открытым.