Czy w DDD logika aplikacji do sprawdzania poprawności czy logika domeny?

26

Załóżmy, że modelujemy formularz za pomocą DDD; formularz może wiązać się z pewnymi regułami biznesowymi - być może będziesz musiał określić dochód, jeśli nie jesteś studentem, i musisz podać swoje dzieci, jeśli wykażesz, że jesteś w związku małżeńskim. A jeśli podałeś kraj, powinien on mieć prawidłowy kraj.

Czy tego rodzaju sprawdzanie poprawności znajduje się w warstwie domeny lub aplikacji? Kilka innych problemów, które rozważałem:

  • Niektóre frameworki, takie jak Laravel, zapewniają reguły sprawdzania poprawności, które mogą sprawdzać poprawność danych wejściowych, zanim żądanie trafi do kontrolera. Czy łamie DDD, jeśli sprawdzanie poprawności odbywa się na tym poziomie?

  • W przypadkach takich jak ustalenie, czy dany kraj jest ważny, zwykle po prostu przeszukuję tabelę bazy danych wszystkich krajów na świecie. Jednak w DDD jest to możliwe (z mojego zrozumienia) na warstwie domeny. Czy warstwa domeny ma dostęp do bazy danych, czy też muszę użyć wyszukiwania innego niż SQL, aby określić prawidłowy kraj?

  • Czy konieczne jest sprawdzenie poprawności danych wejściowych zarówno w aplikacji, jak i na poziomie domeny?

Extrakun
źródło
6
Twoje pytanie zakłada, że ​​zawsze jest jedno, poprawne miejsce na wszystko. Nie ma
Robert Harvey,
1
Co mówi @RobertHarvey. Sprawdzanie poprawności powinno zawsze odbywać się na modelu, niezależnie od sprawdzania poprawności przez „aplikację” (czy model nie jest częścią aplikacji?). Każda walidacja w „aplikacji” powinna być jedynie powtórzeniem walidacji modelu - w celu zwiększenia responsywności interfejsu użytkownika, lub powinna być powiązana tylko z logiką „aplikacji” (jak w: „w tym formularzu można tylko wpisać. .. ”, ale zakładałem walidację encji). Nigdy nie ufaj warstwie „aplikacji” do sprawdzania poprawności domeny, może to nie być twój klient wysyłający informacje ...
Marjan Venema

Odpowiedzi:

29

Czy tego rodzaju sprawdzanie poprawności znajduje się w warstwie domeny lub aplikacji?

Podanie. Magicznym wyszukiwanym hasłem jest warstwa antykorupcyjna

Zazwyczaj wiadomość otrzymana przez twoją aplikację będzie miała smak DTO. Twoja warstwa antykorupcyjna zazwyczaj tworzy typy wartości rozpoznawane przez domenę. Rzeczywiste polecenie wysłane do modelu domeny będzie wyrażone w kategoriach zweryfikowanych typów wartości.

Przykład: polecenie DepositMoney prawdopodobnie zawiera kwotę i typ waluty. Reprezentacja DTO prawdopodobnie wyraziłaby kwotę jako liczbę całkowitą, a kod waluty jako ciąg. Warstwa antykorupcyjna przekształciłaby DTO w typ wartości depozytu, który obejmowałby zweryfikowaną kwotę (która musi być nieujemna) i zweryfikowany CurrencyCode (który musi być jednym z obsługiwanych kodów w domenie).

Po pomyślnym przeanalizowaniu polecenia w typy, które model domeny rozumie, polecenie jest wykonywane w domenie, co może nadal odrzucić polecenie z tego powodu, że naruszyłoby niezmienność biznesową (konto jeszcze nie istnieje, konto jest zablokowane, to konkretne konto nie może używać tej waluty? itp.).

Innymi słowy, weryfikacja biznesowa będzie miała miejsce w modelu domeny, po tym jak warstwa antykorupcyjna zweryfikuje dane wejściowe.

Wdrożenie reguł sprawdzania poprawności będzie zwykle działało albo w konstruktorze typu wartości, albo w metodzie fabrycznej użytej do budowy typu wartości. Zasadniczo ograniczasz konstrukcję obiektów, aby zagwarantować ich poprawność, izolując logikę w jednym miejscu i wywołując ją na granicy procesu.

VoiceOfUnreason
źródło
Dlaczego zastosowanie jest odpowiedzią? Zgodnie z tekstem formalnej weryfikacji można dokonać zarówno w domenie lub w aplikacji, jak i weryfikacji biznesowej tylko w domenie.
inf3rno
@ inf3rno, ponieważ pytania konkretnie zadane na temat sprawdzania poprawności formularza, który nie jest związany z domeną
harmonogram
1
Ta odpowiedź nie ma sensu. Warstwa antykorupcyjna DDD to dodatkowy kod, który piszesz w celu przetłumaczenia na / z zewnętrznego modelu domeny (innego systemu) i modelu domeny aplikacji opartej na DDD. Jeśli nie ma takiego systemu zewnętrznego, nie ma warstwy antykorupcyjnej. Ponadto sprawdzanie poprawności reguł biznesowych należy do modelu domeny (i warstwy domeny), a nie warstwy aplikacji. Jeśli chodzi o DTO, jest to komponent techniczny (w warstwie aplikacji), który może, ale nie musi istnieć w aplikacji DDD. Konwersja między DTO a obiektami / ValueObjects nie ma nic wspólnego z warstwami antykorupcyjnymi.
Rogério,
5

Twój problematyczny model domeny obejmuje reguły biznesowe domeny. Reguły biznesowe są ograniczeniami elementów modelu. Oznacza to, że winda nie porusza się przy otwartych drzwiach, że towary łatwo psujące się nie są ładowane do nie schłodzonego kontenera, a anulowane zamówienie nie jest wysyłane.

Nie oznacza to, że gdy domena wchodzi w interakcje z ludźmi (za pośrednictwem ekranów, formularzy itp.), Nie trzeba jej sprawdzać ani udzielać pomocy. Po prostu uświadom sobie, że jest to opcjonalne.

Należy wziąć pod uwagę, że istnieją dwa typy reguł biznesowych: - reguły właściwości ograniczające atrybuty obiektu oraz reguły współpracy ograniczające dodawanie i usuwanie współpracy między obiektami.

Reguły biznesowe różnią się od reguł logicznych związanych z językiem programowania i sprawdzają, czy wartości zostały dostarczone i czy nie mają wartości zerowej itp.

Uwaga: w DDD nie ma koncepcji „modelowania” formularza.

aryeh
źródło
0

Czy określony stan spowodowałby unieważnienie modelu? Jeśli tak, to model musi uniemożliwić jednostce przejście do tego stanu. Oznacza to, że model musi wiedzieć, jak się zweryfikować.

Istnieje jednak niewielki problem: sprawdzanie poprawności modelu często dzieje się zbyt późno. Często chcemy dokonać weryfikacji wcześniej, aby użytkownik nie musiał czekać zbyt długo. Dlatego sprawdzanie poprawności jest często umieszczane w logice aplikacji.

Jeśli chodzi o kontekst sprawdzania poprawności: nie ma problemu z tym, że jednostka może zapytać o dodatkowe dane. Ale to nie powinno obchodzić, skąd pochodzą te dane. Nie obchodzi go, czy pochodzi z SQL, pliku, czy jest po prostu zakodowany. Właśnie dlatego istnieją repozytoria. Domena określa, jakiego rodzaju zapytania potrzebuje i pozwala komuś zająć się implementacją.

Euforyk
źródło
-2

Warstwa domeny powinna zawierać całą logikę sprawdzania poprawności. Prezentacja, warstwy antykorupcyjne lub inne warstwy zależne powinny to odzwierciedlać.

Barry Faassen
źródło