Представление Богатых Доменных Объектов как сервис

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Надеюсь, это поможет.

Answer 3

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

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

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

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

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

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

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

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