Поздний ответ, но я бы все-же добавил одну поправку к комментам
egor_nullptr и
yurygolikov : утверждая что домен может напрямую иметь связь с инфраструктурой является некорректным ответом во всех случаях.
Я бы привел для примера более наглядную картинку а именно вот эту:
Она почти идентична той что была приведена выше, только её воспринимать можно легче, а именно то что инфраструктура может быть связанна со всеми слоями но только в виде зависимости.
Что это означает?!
Означает это то что в каждом слое есть свои контракты (интерфейсы) которые описывают собственные требования к своим зависимостям, а именно к инфраструктуре в данном конкретном примере, которые обязательны для корректной работы конкретного слоя.
Я понял что имел введу Юрий, но это избавляет от всех плюшек которые предоставляет ДДД идеология, а именно гибкость и легкая возможность замены любого слоя безболезненно для других. (А мы живем в такое время когда инструменты очень быстро "выходят из моды").
Вам дали уже верный ответ, но я бы хотел дополнить второй пункт только:Это я говорю по опыту а не по книжкам.
Интерфейс нужен если вы пишите длительный проект, (но верно, он НЕ обязательный) вам только надо понять почему это так.
Например если вы используете сторонние либы для этой задачи то лучше заводить сразу интерфейс и адаптеры к нему, так как рано или поздно инструмент уже не подходит для бизнеса и надо его менять. А без интерфейса не вы так другие члены команды неосознанно привяжут вашу логику высшего слоя к конкретной библиотеке и замена превратится в длительный рефакторинг целого проекта вместо его развития.
ДДД это идеология которая позволяет писать проекты поддержка которых является более легкой. И именно это надо учитывать при написании любой части кода. Если класс используется в двух сервисах только и больше нигде, то думать о контрактах надо тогда когда появляется необходимость, но если заводится гидратор, то это уже надолго и везде, и надо принимать меры сразу.
