Интерфейсы в пакете 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. Не завязываться на внутренний класс. Ну и тестировать внутреннюю логику исходя из того что это "Чёрный ящик".