Слои в доменном дизайне

Question

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

Однако ограниченный контекст (с доменом + infra) развертывается как единое целое/развертывается. И слои на самом деле ЛОГИЧЕСКИЕ, а не ФИЗИЧЕСКИЕ. Тогда каково реальное преимущество создания этого виртуального разделителя слоев между доменом и инфраструктурой?

Обновление

В традиционном слоистый домена подход (услуга), как говорят, зависит от инфра слоя. Однако, когда дело доходит до домена DDD/clean/hexagonal architecture, он не зависит от других уровней. Однако событие с чистым/гексагональным подходом до сих пор имеет интерфейс, который реализуется посредством инфракрасного слоя.

Поэтому, если вы используете DDD/гексагональный или традиционный многоуровневый подход, вам все равно придется издеваться над репозиториями и т. Д., Т. Е. Домен фактически не является независимым. Каково твое мнение?

Answer 1

Допущение за Domain Model pattern является то, что модель домена является либо наиболее сложная часть приложения, или часть, которая изменения чаще чем другие части.

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

Это основные преимущества, но есть недостатки. Развязка может сделать базу кода более сложной для навигации, а также будет требовать много сопоставления между слоями. Независимо от того, зависит или нет this is worthwhile (насколько сложна модель домена, какие у вас имеются альтернативы проверки и т. Д.)

Answer 2

Самый большой драйвер - это позволить изменять разные слои, не затрагивая друг друга. Например, я часто тестирую свой доменный уровень независимо от моего уровня инфраструктуры. Я делаю это, издеваясь над своими DAO и репозиториями, это позволяет мои тесты работать намного быстрее и делает их намного менее хрупкими.

Я также использовал его, когда мой репозиторий заканчивается необходимостью новой реализации (Oracle vs MS SQL vs Web Service). Это значительно уменьшает вашу сложность, когда вам не нужно переписывать все ваше приложение, когда внешняя служба изменяется из-под вас.

И наконец, расщепление, как правило, помогает вам выполнить SRP. Интеграция уровня вашей базы данных в ваш доменный слой позволяет вам пропустить это (по крайней мере, в моем опыте). Это не заставляет вас, но это, безусловно, поощряет плохое поведение.

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