Протечка или какие зависимости могут быть между слоями в DDD?

Question

[nepster-web]

Изучаю DDD и взялся рефакторить архитектуру приложения с помощью данного подхода.
Есть 4 слоя:
- Application
- Domain
- Infrastructure
- Presentation

Все это дело собирает Application Module средствами фраэморка LUMEN.

У меня есть вопросы касательно связанности между слоями Application, Infrastructure и Presentation.

К примеру у нас есть гидратор, который может конвертировать сущность в массив и наоборот. Как я понял его место в Infrastructure. И этот гидратор мне нужен в Application и Presentation. Причем из-за типов данных гидратор весьма узкоспециализированный, поэтому особо в интерфейсе не нуждается.

class Hydrator {
    public function hydrate(array $data, string $className): object
    {
    }
    public function extract($entity): array
    {
    }
}

Мне ничего не остается как напрямую дергать класс Infrastructure в Application и Presentation слоях.

От сюда вопросы:
1. Может ли Application и Presentation слои зависеть от Infrastructure?
2. Есть ли смысл в данной ситуации делать интерфейс на Hydrator ?

Comments

[yurygolikov]

Добавлю, что в DDD главное выделить слой Домена. Остальные слои не обязательны. Есть разные варианты отделения доменного слоя от остальных. Советую почитать IDDD Vaughn Vernon.

[nepster-web]

Денис Ефремов, extract это обратный процесс из сущности в массив. В моем случае нужен для отдачи в GraphQL

[nepster-web]

Денис Ефремов, не совсем понимаю, что вы пытаетесь до меня донести. Изначально был вопрос не совсем о коде реализации, а скорее филосовский на тему связанности слоев в ddd.

Answer 1

[egor_nullptr]

Presentaion > Application > Domain > Infrastructure
Всё просто: слева направо вызывать можно даже с пропуском слоя, справа налево - нет.

Ответы:
1. Могут.
2. Если подразумевается несколько реализаций, то да.

Comments

[nepster-web]

Не совсем понял. Инфраструктура же должна знать о домене а домен он ней нет.

[nepster-web]

Возможно вы местами перепутали домен и инфраструктуру ?

[yurygolikov]

nepster-web, Ничего не перепутано. Все верно описано.

[nepster-web]

yurygolikov, объясните , почему домен должен знать о инфраструктуре ?

[yurygolikov]

Потому что домен использует инфраструктуру. Вообще если по правильному, то домен знает об интерфейсе к инфраструктуре, который лежит на доменном уровне. То есть он знает только то, что ему нужно, а не то как это реализовано внутри.
А вообще подобная слоистая архитектура это не DDD. Это лишь один из методов выделения доменного слоя.

[nepster-web]

"... домен знает об интерфейсе к инфраструктуре, который лежит на доменном уровне. "
Вот это уже другое дело.
У меня интерфейсы репозиториев лежат в домене, а реализация в ифре.

Изначально была идея вообще все интерфейсы держать в домене. Но если можно обращаться из любого слоя в ифру, то это упрощает жизнь.

А вот, что касается справа на лево, тут невозможно, чтобы инфра не знала о домена, так как во первых интерфейсы, а во вторых те-же репозитроии возвращают сущности, ну и тп.

[yurygolikov]

nepster-web, интерфейсы к инфре можно держать в каждом слое, который к его методам обращается.
Что вы подразумеваее под "справа на лево"? В текущей реализации инфра не должна вызывать домен.

[nepster-web]

yurygolikov, как инфраструктура не может вызывать домен , если она как минимум реализует интерфейсы , которые могут возвращать сущности. Для этого нужен тайпхинт.

[yurygolikov]

nepster-web, ну инфра же не вызывает сущности домена.

[nepster-web]

В некоторых случаях вызывает , например в стратегиях для гидратора. А даже если бы и не вызывала , то из-за тайпхинта будет зависимость на домен.

[yurygolikov]

nepster-web, Вызывать не должна в данной слоистой архитектуре. Зависимость будет. Но инфра вызывать ничего выше не может. Все используют инфру, а не наоборот.

[nepster-web]

yurygolikov, я просто вас понимаю как-то двояко.

В моем понятии инфраструктура это просто реализация репозиториев , сервисов м хелперов , она не вызывает другие слои кроме домена , так как зависит и оперирует сущностями.

[yurygolikov]

nepster-web, Я видимо вас тоже. Что вы подразумеваете под "вызывает". Каким образом у вас инфра к примеру вызывает методы сущностей из доменного слоя?

[nepster-web]

yurygolikov, нет она никак методы не вызывает. Под связанностью я имел ввиду именно тайп хинт.

Например:
...
public function findById(): User
...

Тоесть реализация репозитория возвращает сущность User. И нужно прокинуть нэймспейс из домена.

Именно это я понимаю под связанностью.

Answer 2

[vova07]

Поздний ответ, но я бы все-же добавил одну поправку к комментам egor_nullptr и yurygolikov : утверждая что домен может напрямую иметь связь с инфраструктурой является некорректным ответом во всех случаях.

Я бы привел для примера более наглядную картинку а именно вот эту:


Она почти идентична той что была приведена выше, только её воспринимать можно легче, а именно то что инфраструктура может быть связанна со всеми слоями но только в виде зависимости.
Что это означает?!
Означает это то что в каждом слое есть свои контракты (интерфейсы) которые описывают собственные требования к своим зависимостям, а именно к инфраструктуре в данном конкретном примере, которые обязательны для корректной работы конкретного слоя.

Я понял что имел введу Юрий, но это избавляет от всех плюшек которые предоставляет ДДД идеология, а именно гибкость и легкая возможность замены любого слоя безболезненно для других. (А мы живем в такое время когда инструменты очень быстро "выходят из моды").

Вам дали уже верный ответ, но я бы хотел дополнить второй пункт только:
Это я говорю по опыту а не по книжкам.

Интерфейс нужен если вы пишите длительный проект, (но верно, он НЕ обязательный) вам только надо понять почему это так.

Например если вы используете сторонние либы для этой задачи то лучше заводить сразу интерфейс и адаптеры к нему, так как рано или поздно инструмент уже не подходит для бизнеса и надо его менять. А без интерфейса не вы так другие члены команды неосознанно привяжут вашу логику высшего слоя к конкретной библиотеке и замена превратится в длительный рефакторинг целого проекта вместо его развития.

ДДД это идеология которая позволяет писать проекты поддержка которых является более легкой. И именно это надо учитывать при написании любой части кода. Если класс используется в двух сервисах только и больше нигде, то думать о контрактах надо тогда когда появляется необходимость, но если заводится гидратор, то это уже надолго и везде, и надо принимать меры сразу.

Comments

[yurygolikov]

Я имел ввиду, что еще есть к примеру гексагональная архитектура и архитектура основанная на событиях (EDA).

[nepster-web]

Спасибо за ответ. Да я примерно так и понял и в некоторых случаях действительно у меня есть свои интерфейсы в каждом слое.

Ещё есть один момент , у меня на у очень большое приложение , в котором около 10 модулей , каждый из которых расписан (а точнее рефакторится) по ддд. Это для того , чтобы в дальнейшем было все просто выделить на микросервисы.

Я заметил , что если делать интерфейс в каждом слое , то выходит очень много дублирования. Тоесть не сколько дублирование , а однообразный код и усложнение системы.

Я понимаю , что это более правильно , но в некоторых случаях приходится идти на компромиссы, ради скорости , ради команды.

Поэтому в некоторых случаях я все-же дёргаю инфраструктуру на прямую в других слоях (через интерфейс, которой находится в инфраструктуре).

Что касается гидратора, он улетел в отдельный пакет и стал как зависимость от проекта без адаптеров. Так-как все-же является собственной разработкой.