а у вас будет много адаптеров? если нет - то не нужно
ну как на рисунках в примерах, то там http, console и тесты, так и мне нужно. Просто не до конца понятно от чего отталкиваться в портах - от типа обращения к приложению (http и т.д.) - или от ендпоинтов
представьте что вы раньше общались по rest пред последнего уровня, а потом решили ещё и по rpc общаться, цель гексагона сделать так, чтобы вам не пришлось менять юзкейсы, а только добавить контроллеры ещё и для rpc
Будет что-то типа этого на портах, к примеру? HttpUserLoginController, HttpGetRateController, RpcUserLoginController, RpcGetRateController
в целом да
А порт в этом случае UserLoginContoller и т.д.?
Тут главное понимать отличие портов от просто интерфейсов, и адаптеров от просто реализаций. Например на схеме выше это видно - порты это интерфейсы лежащие внутри, а адаптеры это реализации снаружи. Если положить интерфейсы к реализациям то портами они уже не будут)
контроллеры являются своего рода адаптерами. Ну то есть если ты не будешь зацикливаться на "контроллерах" представь что у тебя есть некая "грань" твоего приложения где с одной стороны порт - "сделать действие" а с другой "сконвертить http запрос в действие" (адаптер). Последнее обычно делают "контроллеры" (или мидлвары или еще кто. Другой гранью может быть взаимодействие с хранилищем (как ты данные достаешь и сохраняешь). Третьей гранью - взаимодействие с каким sms гейтвеем. Внутри интерфейсик снаружи реализация.
Обсуждают сегодня