Предоставление расширенных объектов Домена в качестве сервиса

Question

Я пытался разобраться в том, как предоставить клиенту доступ к объектам моего домена.Независимо от того, использую ли я расширенный клиент или я использую Интернет, я хочу использовать шаблоны MVP и репозитория.

Что я пытаюсь обдумать, так это то, как я предоставляю доступ к своему репозиторию и модели, которые будут находиться на сервере.Возможно ли вообще предоставлять доступ к сложным бизнес-объектам, имеющим состояние, через веб-сервис, или мне придется использовать проприетарную технологию, которая не зависит от языка / платформы, например .Сетевое удаленное управление, EJB, COM +, DCOM и т.д.?

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

С интернетом у вас есть полная свобода действий.Вам не нужно выставлять свои объекты за пределы сервиса, поэтому вы можете сделать их такими богатыми, как вам хотелось бы.Я пытаюсь создать богатую архитектуру N-teir, которая работает, когда клиент, вызывающий модель, находится на другом компьютере.

Answer 1

Вы можете предоставлять доступ к объектам своего домена, как и к любому другому объекту, через REST или веб-службы.Я думаю, главное - понять, что вам придется предоставлять сервисы, которые обеспечивают ценность для бизнеса, за один вызов, и они не обязательно сопоставляют 1: 1 с вашими репозиториями.Таким образом, хотя вы на сервере можете ожидать, что один вызов службы будет использовать несколько репозиториев и выполнять различные агрегации, то, что вы предоставляете через любой веб-сервис, должно быть более или менее полным результатом.Операции, которые вы предоставляете в службе, не должны предоставлять доступ к отдельным репозиториям, а скорее должны быть сосредоточены на значимых операциях, которые обеспечивают заданную ценность для бизнеса.

Я надеюсь, что это в какой-то степени поможет.

Answer 2

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

Если вы хотите, чтобы ваша доменная модель использовалась как сервис, она должна быть разработана как сервис.

Как указано в domain driven design , сервис не имеет состояния, поэтому он не будет предоставлять ваши объекты напрямую.Ваш сервис должен предоставлять методы, обеспечивающие значимые бизнес-операции, которые будут выполняться как единое целое.

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

Answer 3

То, что я пытаюсь обдумать , - это то, как я предоставляю свой репозиторий и модель, которая будет находиться на сервере.Является ли это вообще возможно для раскрытия сложных бизнес-объекты, которые имеют состояние через веб-службу, или мне придется использовать запатентованную технологию, которая не является не зависит от языка / платформы, например .Net удаленное управление, EJB, COM +, DCOM и т.д.?

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

Вместо этого я бы рассмотрел использование такого стиля, как REST или messaging, и определился с интерфейсом, который вы хотите предоставить, а затем сопоставил с доменом / из домена.Итак, если бы вы выбрали REST, вы бы спроектировали свои ресурсы и API (URL, представления и т.д.), А затем вам нужно было бы выполнить это из модели домена.

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

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

Посмотрите на кэширование в HTTP и поддержку нескольких представлений для ресурса, также посмотрите на кэширование в вашем решении для доступа к данным.

Проверка и сообщение об ошибке информация также должна быть отображена пользователю.Я хочу быть в состоянии логически вызывать многие из моих операций с объектами домена, как если бы они были запущены на том же компьютере.

Вы можете либо представить это как ресурс, либо, что более вероятно, посмотреть на коды состояния HTTP и тела ответов, которые вы хотели бы использовать в таких ситуациях.