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

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?

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.

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.

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ą.

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