Я думаю, что вам нужно разделить два типа проверки в этом случае; Проверка домена и проверка приложений .
Проверка приложения - это то, что у вас есть, когда вы проверяете, что свойство команды 'text' содержит от 20 до 200 символов; таким образом, вы проверяете это с помощью графического интерфейса и с помощью средства проверки модели представления, которое также выполняется на сервере после процедуры POST. То же самое касается электронной почты (кстати, я надеюсь, вы понимаете, что электронная почта, такая как `32.d +" Hello World .42 "@ mindomän.local" является действительной в соответствии с RFC).
Тогда у вас есть еще одно подтверждение; проверьте, что статья существует - вы должны задать себе вопрос, почему статья не должна существовать, если действительно есть команда, отправленная из графического интерфейса пользователя, которая предназначена для добавления к ней комментария. Был ли ваш графический интерфейс в конечном итоге непротиворечивым, и у вас есть сводный корень, статья, которую можно физически удалить из хранилища данных? В этом случае вы просто перемещаете команду в очередь ошибок, потому что обработчик команды не может загрузить сводный корень.
В приведенном выше случае у вас будет инфраструктура, которая обрабатывает вредоносные сообщения - они, например, будут повторять сообщение 1-5 раз, а затем перемещать его в очередь сообщений, где вы можете вручную проверить коллекцию сообщений и повторно отправить соответствующие сообщения. Это хорошая вещь для мониторинга.
Итак, теперь мы обсудили:
А как насчет команд, которые не синхронизированы с доменом? Возможно, у вас есть логика в доменной логике, согласно которой после 5 комментариев к статье допускаются только комментарии длиной менее 400 символов, но один парень опоздал с 5-м комментарием и стал 6-м - GUI не уловил его, потому что это не соответствовало домену, когда он отправлял свою команду - в этом случае у вас есть «ошибка проверки» как часть логики вашего домена, и вы должны вернуть соответствующее событие ошибки.
Событие может быть в форме сообщения на брокер сообщений или ваш пользовательский диспетчер. Веб-сервер, если приложение является монолитным, может синхронно прослушивать как событие успеха, так и упомянутое событие отказа и отображать соответствующее представление / частичное.
Часто у вас есть пользовательское событие, которое означает сбой для многих типов команд, и именно на это событие вы подписываетесь с точки зрения веб-сервера.
В системе, над которой мы работаем, мы выполняем запрос-ответ с командами / событиями через шину + брокер сообщений MassTransit + RabbitMQ, и у нас есть событие в этом конкретном домене (частично моделирующее рабочий процесс) с именем InvalidStateTransitionError. Большинство команд, которые пытаются перемещаться вдоль ребра в графе состояний, могут вызывать это событие. В нашем случае, мы моделируем GUI после в конечном итоге непротиворечивой парадигмы, и поэтому мы отправляем пользователя на страницу «команда принята» и после этого позволяем представлениям веб-сервера пассивно обновляться через подписки на события. Следует отметить, что мы также занимаемся поиском событий в совокупных корнях (и будем делать это и для саг).
Итак, вы видите, что многие проверки, о которых вы говорите, на самом деле являются проверками типа приложения, а не реальной логикой домена. Нет проблем в том, чтобы иметь простую модель домена, если ваш домен простой, но вы используете DDD. Однако, продолжая моделировать свой домен, вы обнаружите, что домен может быть не таким простым, каким он показался на первый взгляд. Во многих случаях совокупный корень / сущность может просто принять вызов метода, вызванный командой, и изменить некоторые его состояния, даже не выполняя никакой проверки - особенно если вы доверяете своим командам, как если бы вы проверяли их на веб-сервере, который вы контролируете
Я могу порекомендовать посмотреть две презентации по DDD с Норвежской конференции разработчиков 2011, а также презентацию Грега на Öredev 2010 .
Ура, Хенке