Ответ 1
Говоря о более "классическом" DDD, да, объекты домена, как правило, не допускаются нигде вне домена. Но не абсолютное правило заключается в том, что объекты домена не используются в уровне представления. Например, Naked Objects представляет собой школу мысли, где объекты домена используются напрямую. Я сам придерживаюсь в основном философии, в которой объекты домена не используются напрямую, поэтому я не знаком со всеми практиками, которые они предлагают, я лично думаю, что привязка к объекту домена напрямую будет плохой совет, но... Просто имейте в виду не каждый рассматривает это как требование.
Если вы не разрешаете объекты домена за пределами самого домена, вы обычно используете DTO или объекты передачи данных, которые являются простыми классами свойств, которые не имеют поведения домена. DTO часто отражают структуру модели домена, но не обязательно.
Предполагается, что бизнес-логика будет реализована в модели домена, поэтому многое из того, что находится на прикладном уровне, связано с координацией различных служб, как правило, для переноса данных в клиентские приложения и из них. Для этого многие люди используют некоторую форму SOA или, по крайней мере, веб-службы. Они вызывают репозитории, но также требуют, чтобы другие компоненты, такие как сборщики, принимали объекты домена, возвращаемые из вызовов репозитория, и копировали значения свойств в DTO, которые затем сериализуются и возвращаются вызывающему. Вызывающий часто является ведущим или контроллером, но если вы не используете MVC или MVP, вызывающий объект все равно будет находиться на уровне презентации. Обратное путешествие более сложное - пользовательский интерфейс может отправлять обратно DTO, представляющие обновления или DTO, которые представляют новые объекты, которые будут добавлены. Посредничество этих операций вперед и назад является в первую очередь целью прикладного уровня.
Что касается "не-доступа к данным" уровня домена, существует несколько типичных примеров. Большинство людей обычно ссылаются на компонент "X", о котором вы можете думать как о доменной службе. Служба домена отличается от службы приложений своей близостью к модели домена и наличием фактической бизнес-логики.
Например, если приложение связано с каким-то порядком размещения, на самом деле есть две проблемы: размещение заказов и выполнение заказов. Службы приложений опосредуют передачу данных, необходимых для формулирования размещения заказа, в пользовательский интерфейс, а затем возвращают заказ, который пользователь хочет разместить. Но это только посредничество в передаче данных, и именно там заканчиваются Application Services. Затем может потребоваться доменная служба для применения бизнес-правил и создания дополнительных объектов домена, необходимых для фактического выполнения этого заказа.
В общем, я считаю, что это полезная концепция или метафора, которая может быть применена ко многим сценариям - служба приложений облегчает запрос какого-либо рода с точки зрения запроса . С другой стороны, доменная служба облегчает выполнение запроса .
Единственный другой способ "доступа", отличный от ориентированного на данные, с которым я столкнулся или могу легко представить, - это ориентированная на процесс функциональность. Это не встречается в каждом приложении, но распространено в определенных областях. Например, в сфере здравоохранения, где я работаю, вам могут потребоваться приложения, которые включают в себя важные элементы управления как клиническими данными, так и клиническим процессом. Я решаю эту проблему, не делая этот процесс акцентом частью моей модели домена и использую для этого разные инструменты.
Методы ООП не очень хорошо подходят для самого реального процесса, они полезны для предоставления данных и сбора данных из процесса. Объектно-ориентированная ведь в первую очередь ориентирована на существительное. Для управления процессом в реальном времени вам нужно "глагольное ориентированное программирование" больше, чем "ориентированное на существительное программирование". Инструменты рабочего процесса являются "ориентированными на глагол" инструментами, которые могут дополнять модели, управляемые доменом, для приложений, которые являются как интенсивными, так и интенсивными процессами. Я выполняю большую работу, которая включает в себя как модели С# DDD, так и модели Workflow Foundation, но опять же это необходимо только для определенных типов приложений. Для многих типичных бизнес-приложений требуются только модели и службы домена.
Наконец, самым важным аспектом DDD является не какой-либо метод или архитектура. Реальное сердце этого вращается вокруг Вездесущего языка и взаимодействия с (в моем сильном мнении DIRECT-взаимодействии с) экспертами по доменам, чтобы отделить критические знания домена. (Большинство компаний, которые утверждают, что делают DDD, по-моему, не потому, что многие компании отказываются напрямую взаимодействовать с бизнесом и развитием, но это еще одна тема...) Это экстракция и включение знаний домена, а не любых метод, который фактически отделяет DDD от обычного ООП, и именно там возникает реальная ценность DDD.
ИЗМЕНИТЬ
Что касается использования репозитория, диаграмма верна. Обычно прикладной уровень всегда проходит через репозиторий для объектов домена. Прежде всего, вы должны иметь возможность доставлять данные в приложение, и большинству приложений также необходим определенный уровень запросов.
Уровень домена OTOH обычно не взаимодействует с репозиториями. Как правило, вы хотите, чтобы модель домена была автономной и отделялась от какой-либо конкретной технологии, то есть должна представлять собой "чистое знание домена". Стойкость по своей сути тесно связана с какой-то конкретной технологией, поэтому в целом люди стремятся сделать свои модели домена свободными от реализации настойчивости. У вас есть репозитории, но вы обычно не хотите вызывать методы репозитория в модели домена.
В рамках самой модели домена объекты получаются либо как новые объекты (которые могут быть созданы непосредственно или через factory), либо достигнуты путем обхода ассоциаций. Иногда при создании нового объекта нецелесообразно передавать все необходимое в конструктор, так что это один случай, когда вам может понадобиться какой-то доступ к данным в самой модели домена. Обычно то, что делают люди, проходит через службу данных через интерфейс, так что модель домена может быть обеспечена доступом к данным, но остается изолированной от реализации уровня данных. Но по большей части объекты домена действуют и взаимодействуют с другими объектами домена, которые уже созданы.