Comments 8
На иллюстрации гексагональной архитектуры естественно ожидать какой-нибудь шестиугольник или шестисторонник. Но в статье десятиугольник, декагон какой-то.
То есть на самом деле описана декагональная архитектура или гексагон который про архитектуру на иллюстрации отсутствует? :-)
в гексагональная архитектуре, слово гексагональный указано условно, что архитектура имеет много граней. Эта архитектура имеет альтернативное название - архитектура портов и адаптеров.
Количество граней никак не влияет на тип архитектуры. Вся заморочка с "гексагональной" визуализацией, только для простоты восприятия.
Как происходит общение между контекстами? Если, к примеру, нужно получить в контексте Баннер список товаров из контекста Рекомендации?
Если фреймворк предоставляет библиотеку для работы с чем либо, как ее протягиваете в доменный слой?
Как происходит общение между контекстами? Если, к примеру, нужно получить в контексте Баннер список товаров из контекста Рекомендации?
Практика проекта - использование сервисов уровня приложения в необходимом контексте. В примере из вопроса - мы бы воспользовались сервисом Рекомендации в сервисе Баннеров.
Если фреймворк предоставляет библиотеку для работы с чем либо, как ее протягиваете в доменный слой?
Сейчас у нас в доменном слое в основном аннотации для поднятия бинов. Если есть необходимость в сторонне библиотеке в домене - оборачиваем её в наше понятие и используем. Интересен был бы пример библиотеки.
Подскажи пожалуйста, как вы осуществляете проверки инвариантов, которые зависят на внешних данных (запросы через инфраструктурный слой)?
Например:
делаем проверку на основе ответа GRPC ручки (допустим проверяем ФичаФлаг)
делаем проверку на присутствие каких-то данных в БД, одним запросом (нет возможности подгрузить эти данные из БД, потому что данных много)
Одна из самых исчерпывающих статей по гексагональной архитектуре
Есть же перевод тут же, на Хабре : https://habr.com/ru/post/427739/
Гексагональная архитектура и DDD на опыте интернет-магазина Спортмастер. Пробуем новое