Интерфейсы в пакете application.port обеспечивают ту самую слабую связность из статьи. Это ширма между бизнесовым кодом и адаптерами, которые взаимодействуют с внешними системами. Ещё, можно о port думать как о контракте внутренней логики:
То, что лежит в application.port.in описывает как внутреннюю логику можно вызывать. А то, что лежит в application.port.out ожидает от реализации соответствующих адаптеров в adapter.out
С одной стороны позволяет подменить один адаптер другим. Например, наше приложение использует кэш: class MemcachedAdapter implements CacheGetPort, CachePutPort
В любой момент мы можем подменить этот класс другим главное чтобы он реализовывал интерфейсы CacheGetPort, CachePutPort
С другой стороны, для адаптеров позволяет отвязаться от конкретной реализации из application.domain.service. Не завязываться на внутренний класс. Ну и тестировать внутреннюю логику исходя из того что это "Чёрный ящик".
Интерфейсы в пакете
application.port
обеспечивают ту самую слабую связность из статьи.Это ширма между бизнесовым кодом и адаптерами, которые взаимодействуют с внешними системами.
Ещё, можно о port думать как о контракте внутренней логики:
То, что лежит в
application.port.in
описывает как внутреннюю логику можно вызывать.А то, что лежит в
application.port.out
ожидает от реализации соответствующих адаптеров вadapter.out
С одной стороны позволяет подменить один адаптер другим.
Например, наше приложение использует кэш:
class MemcachedAdapter implements CacheGetPort, CachePutPort
В любой момент мы можем подменить этот класс другим главное чтобы он реализовывал интерфейсы
CacheGetPort
,CachePutPort
С другой стороны, для адаптеров позволяет отвязаться от конкретной реализации из
application.domain.service
. Не завязываться на внутренний класс. Ну и тестировать внутреннюю логику исходя из того что это "Чёрный ящик".