Когда говорим о гексагональной архитектуре, то основное - это блоки, у которых есть порты входа и выхода. Интерфейсы (контракты), через которые идет общение с этими блоками и никак иначе.
Как может быть иначе? У любого модуля есть некий интерфейс через который с ним общаются.
Вот такой на лету выдуманный пример. Есть несколько разных блоков/модулей. А выход один - пдф, как тут быть? Считаем что у каждого блока свой выход? Но выход-то один.
Например из сервиса одного модуля, вызвали репозиторий другого и работем с его сущностями.
Непонятно. Что такое модуль в данном случае? Репозиторий это слой данных, как репозиторий может принадлежать какому-то модулю?
Мне кажется что без знания типичной архитектуры начала 2000-х годов трудно понять что это и зачем. Толстые десктопные клиенты, повсеместная двухзвенка, а то и файл-серверные приложения, бизнес-логика в хранимках, bad delphi style с бизнес логикой прямо в обработчиках событий от ui типа пары сотен строк кода в онклике, dataaccess компоненты, которые самостоятельно лезут в базу, типа добавил строку в гриде, в базу insert.
Все вышеперечисленное в те времена было нормой, несло свой проблемы и поэтому смысл в разделении есть. Но отдельное название только путает людей.
Потыкавшись по интернетам я нашел обсуждение данной архитектуры от автора.
I am a symmetrist at heart. I wish everything to be symmetric at some moment, and work the differences from there. So I create a symmetric version of the layered model, in which the UI is not the front and the DB the back, but both are simply OUTSIDE.
Вся эта гексагональная архитектура не более чем "symmetric version of the layered model".
Еще из забавного от автора
Finally, after many years, I understood better what this architecture is about, and have shifted to calling it PortsAndAdaptersArchitecture
Автор после многих лет понял что правильное название архитектура портов и адаптеров. А народ статьи пишет. Кто-то поди еще и внедряет новинку 2005 года.
To break up perceptions about top and bottom and left and right, I drew it with a hexagonal shape, and came up with the rather stupid name HexagonalArchitecture - because I could not think of what the 'hexagon' meant.
because I could not think of what the 'hexagon' meant. Разве не прекрасно?
Полностью согласен, от того что 3 слоя свернули суть не меняется. Хотел узнать про разницу от автора статьи. Но автор похоже просто переводчик и переводит все подряд.
Когда уровень доступа к данным находится внизу, вся система проектируется на основе того, как устроена база данных.
А если доступ к данным на картинке не снизу, а сбоку, то все хорошо становится? Смысл отдельного уровня доступа данным как раз в абстракции. Как "нахождение снизу" этому мешает?
Не лучше ли начать с бизнес-логики приложения?
Если лучше начать с бизнес-логики, то как многоуровневая архитектура этому мешает?
Port // Порт
Информативное описание, без перевода тут никак.
Основная идея гексагональной архитектуры заключается в том, чтобы отделить бизнес-логику от деталей реализации. Это достигается путем разграничения проблем с помощью интерфейсов.
В обычной трехслойной архитектуре идея та же самая. Так в чем разница?
Может в условной Москве, оно и распродано. Да и там тот же ЗиЛ вроде как относительно недавно разобрали. Необязательно строить завод в центре города, можно построить на окраине, один фиг это гораздо удобнее чем строить завод в деревне пусть даже на 1000 человек.
Третий проект — определение местоположения по звёздному небу для движущихся летательных аппаратов. Например, что было нужно, чтобы самолёт мог определить местоположение
Так все-таки, если кандидат не может ответить на большую часть технических вопросов, то откуда у него "неплохие навыки" и "классный опыт"? Если это неважно, почему отказываете? Если важно, почему они хорошие? Непонятно.
Сами пишете что навык прохождения собеседования и навык работы это разное, но вместо того чтобы поменять процесс собеседования, пишете как надо поменяться кандидату. Вам кто нужен в итоге, кто умеет работать или проходить собеседования? Опять непонятно.
Формально был, тут не поспоришь. А по факту был 3 дня и то произошел серьезный сбой.
Из статьи вообще непонятно что именно произошло. Случилась блокировка (которой быть не должно вообще в принципе, хе-хе), посмотрели список процессов и попробовали разблокировать зависший и это получилось. Никаких подробностей нет. Как из этого можно сделать какие-то выводы о неких механизмах языка? И где тут возможности языка и где возможности среды исполнения?
Как по мне так это отличный пример нездорового фанатизма. Человек фанат лиспа, ничего больше не знает(по крайней мере это неявно следует из статьи) и сует этот лисп повсюду просто потому что потому.
Какая разница снизу слой доступа к данным на картинке или сбоку? Зависимость от этого никуда не девается.
Не совсем понял что имеется в виду под "прямой" зависимостью, но ничего не мешает добавить интерфейс.
Теперь понятно что имеется в виду, спасибо.
Это вообще от архитектуры не зависит. Как можно работать не по публичным контрактам модуля? Ковыряться в сырой памяти или reflection использовать?
Получается нужно три модуля, заказов, доставки и некий общий модуль.
Опять вопрос - что такое модуль? И в данном примере, если модуль Orders (или любой другой) использует модуль Users, это получается нормально?
Вот. А где были бы эти два вызова? Это какой-то отдельный модуль, что это за сущность, где вот этот код
Как может быть иначе? У любого модуля есть некий интерфейс через который с ним общаются.
Вот такой на лету выдуманный пример. Есть несколько разных блоков/модулей. А выход один - пдф, как тут быть? Считаем что у каждого блока свой выход? Но выход-то один.
Непонятно. Что такое модуль в данном случае? Репозиторий это слой данных, как репозиторий может принадлежать какому-то модулю?
Мне кажется что без знания типичной архитектуры начала 2000-х годов трудно понять что это и зачем. Толстые десктопные клиенты, повсеместная двухзвенка, а то и файл-серверные приложения, бизнес-логика в хранимках, bad delphi style с бизнес логикой прямо в обработчиках событий от ui типа пары сотен строк кода в онклике, dataaccess компоненты, которые самостоятельно лезут в базу, типа добавил строку в гриде, в базу insert.
Все вышеперечисленное в те времена было нормой, несло свой проблемы и поэтому смысл в разделении есть. Но отдельное название только путает людей.
Потыкавшись по интернетам я нашел обсуждение данной архитектуры от автора.
Вся эта гексагональная архитектура не более чем "symmetric version of the layered model".
Еще из забавного от автора
Автор после многих лет понял что правильное название архитектура портов и адаптеров. А народ статьи пишет. Кто-то поди еще и внедряет новинку 2005 года.
because I could not think of what the 'hexagon' meant. Разве не прекрасно?
Полностью согласен, от того что 3 слоя свернули суть не меняется. Хотел узнать про разницу от автора статьи. Но автор похоже просто переводчик и переводит все подряд.
А если доступ к данным на картинке не снизу, а сбоку, то все хорошо становится? Смысл отдельного уровня доступа данным как раз в абстракции. Как "нахождение снизу" этому мешает?
Если лучше начать с бизнес-логики, то как многоуровневая архитектура этому мешает?
Информативное описание, без перевода тут никак.
В обычной трехслойной архитектуре идея та же самая. Так в чем разница?
Может в условной Москве, оно и распродано. Да и там тот же ЗиЛ вроде как относительно недавно разобрали. Необязательно строить завод в центре города, можно построить на окраине, один фиг это гораздо удобнее чем строить завод в деревне пусть даже на 1000 человек.
машиностроение в деревне это сильно
Я к тому, что астрокорекция используется МБР.
Точно самолет? Или что-то другое)
Можно уточнить, если не помнишь. Видите какой хороший вопрос, заодно и софтскилы проверяет)
Особенно когда есть 5 - 10 вакансий, а там задание на 1 - 3 дня.
Как-то так себе результат.
Так все-таки, если кандидат не может ответить на большую часть технических вопросов, то откуда у него "неплохие навыки" и "классный опыт"? Если это неважно, почему отказываете? Если важно, почему они хорошие? Непонятно.
Сами пишете что навык прохождения собеседования и навык работы это разное, но вместо того чтобы поменять процесс собеседования, пишете как надо поменяться кандидату. Вам кто нужен в итоге, кто умеет работать или проходить собеседования? Опять непонятно.
Формально был, тут не поспоришь. А по факту был 3 дня и то произошел серьезный сбой.
Из статьи вообще непонятно что именно произошло. Случилась блокировка (которой быть не должно вообще в принципе, хе-хе), посмотрели список процессов и попробовали разблокировать зависший и это получилось. Никаких подробностей нет. Как из этого можно сделать какие-то выводы о неких механизмах языка? И где тут возможности языка и где возможности среды исполнения?
Как по мне так это отличный пример нездорового фанатизма. Человек фанат лиспа, ничего больше не знает(по крайней мере это неявно следует из статьи) и сует этот лисп повсюду просто потому что потому.
В сухом остатке - LISPа на марсоходе не было. А там где он был случился серьезный сбой. Так себе результат. В общем, опасайтесь "евангелистов".