Порты, адаптеры и луковицы — или просто слоёная с правилами?

У нас имеется базовая слоеная архитектура. Также мы имеем различные дизайнерские практики и паттерны, которые включают принципы ООП, SOLID, DAO, паттерны проектирования, подход «программирования через интерфейсы» и др. До 2005 года указанные практики использовались просто как элементы дизайна в слоеной архитектуре без создания отдельной архитектурной парадигмы. После 2005 года сообщество выделило из слоеной архитектуры несколько её подвидов, различающихся по направлению зависимостей в коде и степени изоляции слоёв (упрощённо). Исторически указанные подвиды стали называть самостоятельными архитектурами. Считается, что классическая слоеная архитектура не имеет особых правил и хорошо подходит для CRUD-приложений (без бизнес-логики), следствием чего смотрится комком грязи в коде (спорный вывод и не мой). Гексагональная архитектура (2005 год) вводит правило изоляции домена посредством создания интерфейсов слоя доступа к данным и сервисного слоя. Указанные интерфейсы называются входными и выходными портами, а их реализации входными и выходными адаптерами (обычно веб и доступ к базе данных). В целом речь идёт об инверсии зависимостей и изоляции слоёв. Самый простой вариант слоеной архитектуры, позволяющий оперативную смену реализации контрактов и независимое тестирование бизнес-логики через фейки. Луковая архитектура рассмотрела те же вопросы под другим углом зрения с созданием другой терминологии. По сути, она ничем не отличается от гексагональной, кроме того, что в ней не делается главный акцент на порты и адаптеры. Чистая архитектура ещё одна интерпретация тех же принципов с более детальной проработкой правил изоляции слоёв приложения. Все три — это не разные технические парадигмы, а разные терминологические системы для одной и той же идеи. Различия в структуре. Общность в механике. Необходимо заметить, что все вышеперечисленные практики можно использовать по отдельности в классической слоеной архитектуре, а можно комплексно с соответствующим именованием. В первом случае у нас остаётся простая слоеная архитектура, а при комплексном подходе специализированная разновидность слоеной (гексагональная, луковая или чистая). В классической слоеной зависимости направлены сверху вниз, в остальных к центру (зависимость это импорт в коде). Главным достижением новых архитектур считают перенесение интерфейса доступа к данным в слой домена из слоя персистентности. Обоснование, возможность независимого тестирования бизнес-логики и оперативной смены базы данных. Следует подчеркнуть, что нахождение этого интерфейса в слое персистентности даёт те же самые возможности, при условии соблюдения тех же принципов изоляции. Чтобы не оставаться в пространстве слов даю ссылки на свои два репозитория. https://github.com/architectural-styles/architecture-layered-sample https://github.com/architectural-styles/architecture-hexagonal-sample Одна задача, три реализации БД, одинаковая пирамида тестирования. Единственное отличие: в первом интерфейс репозитория лежит в слое персистентности, во втором в слое домена. Замена реализации работает в обоих. Независимое тестирование бизнес-логики работает в обоих. «Миграция» между ними заняла один час и не затронула ни строчки логики. Только переименование пакетов. Это не доказывает, что гексагональная архитектура не нужна. Это доказывает, что хорошо написанная слоеная архитектура уже гексагональна по сути. При соблюдении дисциплины разница исчезает. Подробнее в статье: A well-structured layered architecture is already almost hexagonal. Ссылка - https://www.reddit.com/r/softwarearchitecture/comments/1rr1r80/a_wellstructured_layered_architecture_is_already/ Ссылка - https://www.linkedin.com/pulse/well-structured-layered-architecture-already-almost-hexagonal-russu-vy3wc/ Центральный термин обоснования эксклюзивности гексагональной архитектуры — «обладание контрактом домена» — не даёт дополнительных технических гарантий. Само по себе нахождение интерфейса персистентности в слое домена никоим образом не препятствует именованию его методов в стиле CRUD, а не доменной логики. Сторонники гексагональной архитектуры могут возразить: когда интерфейс лежит в домене, следующий разработчик видит границу физически. Это когнитивная инженерия, и её не стоит недооценивать. Это справедливо. Точнее описать это так: интерфейс в домене — это сигнал о том, кто диктует форму контракта. Не база данных говорит бизнес-логике, как с ней говорить, а бизнес-логика говорит базе данных, что ей нужно. Разница реальная. Но она достигается соглашениями, ревью и ArchUnit независимо от того, как называется архитектура. Главной претензией новичков к указанным архитектурам является наличие отдельных парадигм с разными, но пересекающимися терминологическими системами, а также искусственная усложнённость объяснения, что существенно повышает время обучения, хотя речь идёт о не очень сложных предметах. Дальше субъективно. Но по делу. Я намеренно прошёл через всю цепочку: - изучил материалы по каждой из архитектур, - построил два идентичных проекта с разным расположением интерфейсов, - сравнил возможности и задал прямые вопросы на профессиональных форумах. Результат предсказуем: технических аргументов в пользу эксклюзивности гексагональной архитектуры не нашлось. Нашлись рассуждения про «владение доменом», аналогии с луковицами и шестиугольниками, и финальное признание оппонентов: «никакая архитектура не защитит вас от плохих разработчиков, и хорошие разработчики пишут приличный код в большинстве архитектур». Это честный ответ. Но тогда возникает закономерный вопрос: зачем три отдельные парадигмы с разными словарями, если в основе одни и те же принципы? Ответ лежит не в технике, а в истории. Cockburn, Palermo и Martin работали в разное время и в разных экосистемах. Каждый дал своё имя принципу, который уже существовал в практике. Три названия — это не три технических решения. Это одна идея, которая в разное время получила разное оформление и сформировала отдельные направления со своими терминами и образовательными материалами. Это нормально, но это не повод строить три отдельные вселенные для обучения новичков. Убедиться, что это не частное наблюдение, можно здесь: обсуждение на r/softwarearchitecture на reddit. Ссылка - https://www.reddit.com/r/softwarearchitecture/comments/1s1oif9/the_deception_of_onion_and_hexagonal_architectures/ Те же вопросы, те же круги, те же споры у людей с многолетним опытом. Архитектурное сообщество проделало огромную работу по систематизации практик проектирования. Но где-то по дороге эти принципы обросли терминологией и метафорами. Порог входа вырос непропорционально сложности самих идей. Гексагональная, луковая и чистая архитектуры — это паттерны организации кода, которые делают инверсию зависимостей и изоляцию слоёв явными и предсказуемыми. Это полезно. Но это не революция. Это дисциплина. Анекдот. Один старый капитан, безаварийно проплававший всю жизнь, умирал. Много людей собралось у одра. Все хотели узнать секрет безаварийного судновождения. Капитан сказал: секрет в конверте, вскрыть строго только после смерти. Умер. Вскрыли конверт. Там — зелёный огонь правый борт, красный огонь — левый борт! В прикладном программировании можно так же. Программируй через интерфейсы. Инвертируй зависимости. Изолируй слои. И называй это как хочешь!