Или по доменам: весь код, относящийся к конкретному объекту отправляем в один пакет Это называется либо вертикальный слайсинг, либо разделение bounded контекстов в зависимости от используемого подхода. "По доменам" это называть не совсем правильно. Домен - он один. В рамках баундед контекста выделяется часть домена выделяется в необходимую для сервиса доменную модель
Как следствие, внедрение новых сотрудников занимает гораздо больше времени, чем могло бы. Так могло бы быть, в случае идеальной картины мира, когда разработчики представляют, что такое гексагональные типы агрикультур и как их готовить. На практике, у нас это очень редкое явление, в то время как про трехслойку знают все. И обычно онбординг из-за этого занимает все же больше времени. Другой вопрос, что когда ты уже разобрался с той интерпретаций соответствующего подхода в команде, то разобраться в следующем сервисе действительно становится проще.
В директории гексагонального проекта вы увидите такую структуру... 1) Нет, не увидите. Это уже гораздо более поздние интерпретации. Как вариант луковичная или чистая. Гексагональная архитектура говорила о физическом разделении адаптеров. Каждый адаптер поставлялся в отдельном джарнике, в то время, пока аппликейшн завязана на порты. И это имело строго техническое применение. На дворе, сюрприз, 2005 год. Спринг только год назад в релиз вышел, про ваши девопсы никто даже не слышал. Скорости инета не такие большие. Люди работали на ee стеке. Собирали нужные джарки, по какому нибудь фтп/ссх закидывали их на серв где крутится большой и страшный аппликейшн сервер и благодаря такому подходу могли хот релоуднуть нужный адаптер заменив на новый, в то время как остальное приложение фактически продолжало работать... Идея, что тот же подход можно использовать и в рамках одного проекта появилась на несколько лет позже. Всякие спринги с идеей тупо поднять отдельный сервлет контейнер и перенаправить на него трафик вместо этих сложностей с ее серверами к тому времени активно набирало популярность. И собственно луковичная архитектура как раз об этом. Да, мы не делаем хот релоуды, да, у нас сейчас одна запакованная джарка и все хорошо... Но идея, что во главе стоит бизнес логики, а не контроллеры с репозиториями - здравая и давайте продолжать ее использовать... 2) 1 common и на application и на адаптер... Даже не знаю, что кроме портов с их дто-шками туда можно положить. Но тогда почему бы их так не назвать? Exception-ы ещё, но они обычно тоже отдельно как-то отдельно выносят. Но судя по схеме порты лежат в аппликейшне... Но тогда я совсем не понимаю, что там находится. Они разные и шарить между собой ничего не должны.
| ├── domain/ │ │ ├── model/ │ │ └── service/ Да откуда вы блин все это берёте? На тех схемах, на которые вы же и ссылаетесь домен лежит внутри аппликейшн слоя, показывая, что есть доменная модель, и на базе ее строится аппликейшн. Таким помещением в рамках внутреннего слоя подразумевалось, что домен, как самая внутренняя часть проекта, его сердце, ни на кого не зависит а обозначает сущности, существующие (простите за тавтологию) вне зависимости от существования твоего приложения. Т.е. если бы его не было, все равно люди бы бегали вокруг и на условных бумажках это все делали... А аппликейшн слой - то уровень логики твоего приложения, которая, естественным образом зависит от домена... Что блин это за попытки переложить бл в домен? Причём повальная...
Но простого способа понять утекли ли зависимости я не нашёл Плохо искал. Закон протекающих абстракций не вчера был придуман и пока это были физически разные проекты, которые просто не имели зависимостей друг на друга и ты не мог обратиться к спринговому классу в бизнес логике просто потому, что спринга там не было, то с луковой архитектурой эта проблема уже появилась... И ее учились решать. Сначала каким-то самописными системами проверки, потом появился ArchUnit... и кстати, идея о том, что бл не должна зависеть от фреймворков сформирована только уже только в чистой архитектуре, первые заметки о которой были в 12 году... Быстро вы 7 лет эволюции конечно :D
На это нужно обращать внимание при ревью нового кода. Такая себе идея. Во время ревью кода нужна верхнеуровневая проверка. Автоматика не знает особенностей ваших систем и ревьюеры проверяют, можно ли делать то, что ты делаешь. А проверять стили/зависимости, наличие всяких очевидных плохих практик и пр. должна автоматика.
Гексагональная модель пушит нас для ядра приложения использовать свою внутреннюю модель. Это не гексагональная модель пушит... Люди и наигравшись со слоенкой приходят к тому, что это не адекватно, что когда у тебя меняется апи - падает работа с бд, потому что какое-то поле по другому завется... Но почему? Я ведь апи меняю... А если тебе придётся на бд другую съезжать, а если вдруг у этих бд окажется нужно по разному схемы строить потому что какие-то свои особенности... Не, я понимаю, что конвертеры уже наплохокодили, но... Если уже наступили в лужу и какие-то костыли заиспользовали - окей, но может лучше не наступать?...
Или по доменам: весь код, относящийся к конкретному объекту отправляем в один пакет
Это называется либо вертикальный слайсинг, либо разделение bounded контекстов в зависимости от используемого подхода. "По доменам" это называть не совсем правильно. Домен - он один. В рамках баундед контекста выделяется часть домена выделяется в необходимую для сервиса доменную модельКак следствие, внедрение новых сотрудников занимает гораздо больше времени, чем могло бы.Так могло бы быть, в случае идеальной картины мира, когда разработчики представляют, что такое гексагональные типы агрикультур и как их готовить. На практике, у нас это очень редкое явление, в то время как про трехслойку знают все. И обычно онбординг из-за этого занимает все же больше времени. Другой вопрос, что когда ты уже разобрался с той интерпретаций соответствующего подхода в команде, то разобраться в следующем сервисе действительно становится проще.
В директории гексагонального проекта вы увидите такую структуру...1) Нет, не увидите. Это уже гораздо более поздние интерпретации. Как вариант луковичная или чистая. Гексагональная архитектура говорила о физическом разделении адаптеров. Каждый адаптер поставлялся в отдельном джарнике, в то время, пока аппликейшн завязана на порты. И это имело строго техническое применение. На дворе, сюрприз, 2005 год. Спринг только год назад в релиз вышел, про ваши девопсы никто даже не слышал. Скорости инета не такие большие. Люди работали на ee стеке. Собирали нужные джарки, по какому нибудь фтп/ссх закидывали их на серв где крутится большой и страшный аппликейшн сервер и благодаря такому подходу могли хот релоуднуть нужный адаптер заменив на новый, в то время как остальное приложение фактически продолжало работать... Идея, что тот же подход можно использовать и в рамках одного проекта появилась на несколько лет позже. Всякие спринги с идеей тупо поднять отдельный сервлет контейнер и перенаправить на него трафик вместо этих сложностей с ее серверами к тому времени активно набирало популярность. И собственно луковичная архитектура как раз об этом. Да, мы не делаем хот релоуды, да, у нас сейчас одна запакованная джарка и все хорошо... Но идея, что во главе стоит бизнес логики, а не контроллеры с репозиториями - здравая и давайте продолжать ее использовать...
2) 1 common и на application и на адаптер... Даже не знаю, что кроме портов с их дто-шками туда можно положить. Но тогда почему бы их так не назвать? Exception-ы ещё, но они обычно тоже отдельно как-то отдельно выносят. Но судя по схеме порты лежат в аппликейшне... Но тогда я совсем не понимаю, что там находится. Они разные и шарить между собой ничего не должны.
|
├── domain/│ │ ├── model/
│ │ └── service/
Да откуда вы блин все это берёте? На тех схемах, на которые вы же и ссылаетесь домен лежит внутри аппликейшн слоя, показывая, что есть доменная модель, и на базе ее строится аппликейшн. Таким помещением в рамках внутреннего слоя подразумевалось, что домен, как самая внутренняя часть проекта, его сердце, ни на кого не зависит а обозначает сущности, существующие (простите за тавтологию) вне зависимости от существования твоего приложения. Т.е. если бы его не было, все равно люди бы бегали вокруг и на условных бумажках это все делали... А аппликейшн слой - то уровень логики твоего приложения, которая, естественным образом зависит от домена... Что блин это за попытки переложить бл в домен? Причём повальная...
Но простого способа понять утекли ли зависимости я не нашёлПлохо искал. Закон протекающих абстракций не вчера был придуман и пока это были физически разные проекты, которые просто не имели зависимостей друг на друга и ты не мог обратиться к спринговому классу в бизнес логике просто потому, что спринга там не было, то с луковой архитектурой эта проблема уже появилась... И ее учились решать. Сначала каким-то самописными системами проверки, потом появился ArchUnit... и кстати, идея о том, что бл не должна зависеть от фреймворков сформирована только уже только в чистой архитектуре, первые заметки о которой были в 12 году... Быстро вы 7 лет эволюции конечно :D
На это нужно обращать внимание при ревью нового кода.Такая себе идея. Во время ревью кода нужна верхнеуровневая проверка. Автоматика не знает особенностей ваших систем и ревьюеры проверяют, можно ли делать то, что ты делаешь. А проверять стили/зависимости, наличие всяких очевидных плохих практик и пр. должна автоматика.
Гексагональная модель пушит нас для ядра приложения использовать свою внутреннюю модель.Это не гексагональная модель пушит... Люди и наигравшись со слоенкой приходят к тому, что это не адекватно, что когда у тебя меняется апи - падает работа с бд, потому что какое-то поле по другому завется... Но почему? Я ведь апи меняю... А если тебе придётся на бд другую съезжать, а если вдруг у этих бд окажется нужно по разному схемы строить потому что какие-то свои особенности... Не, я понимаю, что конвертеры уже наплохокодили, но... Если уже наступили в лужу и какие-то костыли заиспользовали - окей, но может лучше не наступать?...