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