Комментарии 3
Есть очень интересный пост (и видео доклада) от Mark Seemann:
https://blog.ploeh.dk/2016/03/18/functional-architecture-is-ports-and-adapters/
https://www.youtube.com/watch?v=US8QG9I1XW0&%3Bfeature=youtu.be
В посте рассматривается архитектура портов и адаптеров (та же гексогональная) со стороны ООП и со стороны ФП. В частности в Haskell, который имеет такую систему типов какую имеет, оказывается архитектура портов и адаптеров является путем наименьшего сопротивления. Что связано в большей мере с механизмом ограничения эффектов.
Таким образом в Haskell воспроизводство некорректной архитектуры в коде требует активных деструктивных действий программиста.
С другой в ООП нужно принимать активные архитектурные решения и знать паттерны, чтобы поддерживать архитектуру и добиться тех же преимуществ.
P.s. не слишком опытный кодер на Haskell
Когда читаешь статьи про архитектуру, очень не хватает более-менее реальных примеров законченных проектов. В жизни компоненты чаще всего не могут быть абсолютно изолированными друг от друга и имеют связи. На каких уровнях должны быть эти связи? К примеру является ли «нормальным» в этой архитектуре использование доменных моделей другого компонента? А общее использование адаптеров, сервисов?
Думаю что реальные такие законченные проекты тяжело встретить, т.к. разработка ПО достаточно молодая отрасль (по сравнению со строительством или медициной например) и пока люди чаще применяют это у себя в закрытых энтерпрайзных проектах + в команде должен быть сильный специалист с такими знаниями. Но кое-что можно найти тут.
Насчет вопроса «на каких уровнях должны быть эти связи»: в этой статье обратите внимание на раздел «Адаптеры», там сказано что у каждого домена можно завести свою папку «Domain» в которой будут храниться собственные порты этого домена. Соответственно внутри одного домена вы сможете использовать функциональность другого подключившись через его порты и адаптеры (здесь так же задействуется Принцип инверсии зависимостей).
Symfony и Гексагональная архитектура