Przekazywanie komend CQRS bezpośrednio do obiektów Domain

Question

~ TLDR: Wdrażam rozwiązanie CQRS + DDD dla jednego z moich większych projektów, i zastanawiam się, czy istnieje prawdziwy powód, dla którego moje programy obsługi komend nie mogą bezpośrednio wysyłać obiekt polecenia do moich agregatów, w niewielkiej liczbie przypadków, gdzie obiekt polecenia jest bogaty w dane? Nie mogę znaleźć żadnego konkretnego powodu, dla którego miałby to być jakiś anty-wzór, i nie mogę znaleźć żadnych opinii, które szczegółowo opisują ten typ projektu.

Tło: Zaimplementowałem już systemy CQRS i mam wdrożone aplikacje DDD, ale nigdy CQRS + DDD w odpowiedniej aplikacji opartej na domenie stylu Eric Evans. Pytam więc, ponieważ nie chcę nadużywać moich Agregatów i zranić mojego wniosku na dłuższą metę.

Przykładem mojego obiektu polecenia zawierającego sporo danych byłoby polecenie rejestracji, które obejmuje 8 + pola (imię, nazwisko, preferowana nazwa, imię i nazwisko, tytuł, nazwa użytkownika, hasło, dział itp.). Czuję się bardzo niezręcznie tworząc na moim Aggregate metodę, która ma 8 par, a alternatywne rozwiązanie użycia jakiegoś dto, a mój przewodnik mapuje polecenie do dto - albo automagicznie używając automappera, albo inline - wydaje się niepotrzebnym i abstrakcja bez wartości dodanej.

Mogę również zobaczyć przyszłe przypadki użycia, w których polecenia mogą być bogate w dane (nie będzie to duży procent poleceń, ale wciąż będzie ich kilka), więc chciałbym, aby ten pozornie banalny aspekt był poprawny od początku.

Answer 1

Obiekty poleceń są zwykle wyrażane w typach pierwotnych, a sygnatury agregatów metod są wyrażane w koncepcjach dziedzinowych.

Fakt, że nie od razu rozpoznajesz, prawdopodobnie oznacza, że ​​przegapiłeś wiele okazji do wyraźnego wyrażenia swoich domysłów.

"komenda rejestracja że bierze w 8+ pól (imię, nazwisko, preferowane nazwisko, data urodzenia, tytuł, nazwa użytkownika, hasło, towarowych itp)"

co należy uderzać że firstname i lastname może z pewnością tworzyć znaczącą całość, taką jak new FullName(firstname, lastname) i jestem pewien, że istnieje wiele innych przypadków, w których obiekty Value (VO) mogą lub powinny być używane w twojej domenie ... Username, Password, itp.? Używanie VO do modelowania rzeczy, które się razem zmieniają, lepiej opisuje twój model, a także zmniejsza liczbę argumentów, które musisz przekazać.

W związku z tym obiekty poleceń są słabymi kandydatami jako argumenty metody agregacji. Jeśli pójdziesz tą drogą, na pewno przegapisz możliwości modelowania.

Answer 2

Zgadzam się z @plalx.

Podejmowanie komend, ponieważ argumenty metody agregacji mogą prowadzić do posiadania zbyt wielu kodów odwzorowań wewnątrz agregatów: Odwzorowywanie typów pierwotnych na obiekty domenowe, które lepiej jest umieszczać poza obiektami domeny.

Ale dla prostszych projektów uważam, że to dobry starter.

W przypadku rejestracji kontekst ograniczony jest zwykle domeną pomocniczą, a złożoność zwykle pochodzi z integracji zewnętrznej (powiadomienie e-mail, rejestracja przy użyciu kont społecznościowych itp.). W tym przypadku myślę, że ograniczona kontekstowa integracja jest ważniejsza niż modele wewnątrz. Przyjmuj polecenia, ponieważ argumenty metod agregacji mogą być szybkim początkiem, aby załatwiać sprawy i oszczędzać czas, aby skupić się na swojej głównej domenie.