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