Myślę, że w tym przypadku musisz oddzielić dwa typy walidacji; walidacja domeny i walidacja aplikacji .
Sprawdzanie poprawności aplikacji polega na sprawdzeniu, czy właściwość polecenia „tekst” ma od 20 do 200 znaków; więc sprawdzasz to za pomocą GUI i sprawdzania poprawności modelu widoku, które również wykonuje się na serwerze po POST. To samo dotyczy wiadomości e-mail (przy okazji, mam nadzieję, że zdajesz sobie sprawę, że wiadomość taka jak `32.d +„ Hello World .42 ”@ mindomän.local” jest poprawna zgodnie z RFC).
Następnie masz kolejną weryfikację; sprawdź, czy artykuł istnieje - musisz zadać sobie pytanie, dlaczego artykuł nie powinien istnieć, jeśli rzeczywiście jest wysłane polecenie z GUI, które dotyczy dołączenia komentarza do niego. Czy twój GUI był w końcu spójny i masz zagregowany katalog główny, artykuł, który można fizycznie usunąć ze składnicy danych? W takim przypadku wystarczy przenieść polecenie do kolejki błędów, ponieważ program obsługi poleceń nie ładuje zagregowanego katalogu głównego.
W powyższym przypadku dysponujesz infrastrukturą, która obsługuje wiadomości o zatruciach - na przykład ponawiają próbę 1-5 razy, a następnie przenoszą ją do kolejki, w której można ręcznie sprawdzić zbiór wiadomości i ponownie wysłać odpowiednie. Dobrze jest monitorować.
Więc teraz omówiliśmy:
Co z poleceniami, które nie są zsynchronizowane z domeną? Być może masz logikę domeny mówiącą, że po 5 komentarzach do artykułu dozwolone są tylko komentarze poniżej 400 znaków, ale jeden facet spóźnił się z piątym komentarzem i musiał być szósty - GUI go nie złapał, ponieważ nie było to zgodne z domeną w momencie wysłania polecenia - w tym przypadku masz „błąd sprawdzania poprawności” jako element logiki domeny i zwracasz odpowiednie zdarzenie awarii.
Zdarzenie może mieć formę wiadomości wysłanej do brokera wiadomości lub niestandardowego programu rozsyłającego. Serwer WWW, jeśli aplikacja jest monolityczna, może synchronicznie nasłuchiwać zarówno zdarzenia pomyślnego, jak i wspomnianego zdarzenia awarii i wyświetlać odpowiedni widok / częściowy.
Często masz niestandardowe zdarzenie, które oznacza niepowodzenie dla wielu rodzajów poleceń, i to jest to zdarzenie, które subskrybujesz z perspektywy serwera WWW.
W systemie, nad którym pracujemy, wykonujemy żądanie-odpowiedź za pomocą poleceń / zdarzeń za pośrednictwem magistrali komunikatów + brokera MassTransit + RabbitMQ i mamy zdarzenie w tej konkretnej domenie (częściowo modelujące przepływ pracy) o nazwie InvalidStateTransitionError. Większość poleceń, które próbują poruszać się wzdłuż krawędzi na wykresie stanu, może spowodować to zdarzenie. W naszym przypadku modelujemy interfejs GUI zgodnie z ostatecznie spójnym paradygmatem, więc wysyłamy użytkownika na stronę „polecenia zaakceptowanego”, a następnie pozwalamy pasywnie aktualizować widoki serwera WWW poprzez subskrypcje zdarzeń. Należy wspomnieć, że zajmujemy się także pozyskiwaniem zdarzeń w zagregowanych korzeniach (i będziemy także robić sagi).
Widzisz więc, wiele z walidacji, o których mówisz, to w rzeczywistości walidacje typu aplikacji, a nie rzeczywista logika domeny. Nie ma problemu z posiadaniem prostego modelu domeny, jeśli twoja domena jest prosta, ale robisz DDD. Jednak w miarę modelowania domeny odkryjesz, że domena może nie być tak prosta, jak się początkowo okazało. W wielu przypadkach zagregowany katalog główny / jednostka może po prostu zaakceptować wywołanie metody spowodowane przez komendę i zmienić niektóre jej stany bez przeprowadzania żadnej weryfikacji - szczególnie jeśli ufasz komendom tak, jak robisz to, jeśli sprawdzasz je na serwerze WWW, który kontrolujesz.
Mogę polecić obejrzenie dwóch prezentacji na DDD z Norwegian Developer Conference 2011, a także prezentacji Grega na Öredev 2010 .
Na zdrowie, Henke