Jak uniknąć anemicznej warstwy domeny i nadal mają bogate reguły sprawdzania poprawności i biznesowe

Question

Jeśli masz obiekt domeny i chcesz zrobić coś użytecznego i kluczowego dla odpowiedzialności tego obiektu domeny, tak jak to jest ważne, czasami potrzebujesz dostępu stan powiązanych obiektów w celu przeprowadzenia tej walidacji.

Jak uniknąć obiektu domeny wymagającego wywołania do repozytorium lub warstwy dostępu do danych? Nie zawsze można przejść relacji kolekcji, nawet z leniwym ładowaniem, ze względu na wydajność, i często chcesz wykonywać kwerendy w obiekcie domeny. Można uzależnić implementację repozytorium w domenie, ale nie jest ono naprawdę czyste i komplikuje testowanie.

Zawsze rozluźniłem rzeczy i umożliwiłem dostęp z domeny do repozytorium za pomocą DI. Nie widziałem wyraźnych przykładów, jak mieć "czystą" warstwę domeny w złożonej aplikacji, która nie jest również anemiczna i ma warstwę usług/aplikacji, wykonującą wszystkie pomruki i pomieszanie z tym, co powinno znajdować się w obiektach domeny.

Answer 1

• Jeśli obiekt jest obiektem wartość, to powinna być niezmienna i zatwierdzone trakcie budowy.

• Jeśli obiekt jest agregat korzeń, a jego własny stan wystarczy powiedzieć jeśli jest ważny czy nie, można dodać metodę sprawdzania na to, co kaskady poprzez agregację.

• Wreszcie, i myślę, że to jest twój główny problemem, jeśli chcesz mieć dostęp kilka podobnych obiektów (które są nie w tym samym łącznie) w celu zapewnienia jeden z nich jest poprawny, ty ostatecznie musi deportować tę logikę w określonej usłudze walidacji.

Naprawdę uważam, że usługi wstrzykiwania i repozytoria w podmioty nie są najlepszym wyborem. Tworzenie dedykowanych usług wydaje się bardziej odpowiednie i nie rozumiem, dlaczego doprowadzi to do posiadania anemicznych obiektów domeny.

Krótko mówiąc, jeśli możesz sprawdzić stan obiektu bez korzystania z usług lub repozytoriów, pozwól, aby obiekt zajął się nim, na poziomie zagregowanym. Gdy potrzebujesz zapytać o usługi lub repozytoria lub kiedy potrzebujesz innych podmiotów, zdecydowanie rozważ przeniesienie tej logiki poza obiekt.

Answer 2

Odpowiedziałem na podobne pytanie zaledwie kilka godzin temu. Odpowiedź zawiera wskazówki, których używam, gdy próbuję wzbogacić mój model o logikę i zachowanie, nie powodując, że jest on brudny w zależności od elementów powiązanych z technologią. Having trouble putting real-world logic into the DDD domain layer

odpowiedź zawiera również linki do innych przydatnych zasobów.

Powodzenia i nie krępuj się napisz do mnie lub zapytaj mnie o DDD i unikaj modeli anemicznych. Jest to interesujący temat, w którym ludzie mają tendencję do rozwiązywania tego na różne sposoby.