CQRS - Czy polecenie powinno próbować utworzyć "złożoną" jednostkę szczegółów?

Question

Czytałem myśli Grega Younga i Udiego Dahana o Rozkazach Rozdziału Odpowiedzialności i wiele z tego, co przeczytałem, uderza we mnie. Moja domena (śledzimy pojazdy, które realizują dostawy) ma koncepcję trasy, która zawiera jeden lub więcej przystanków. Potrzebuję moich klientów, aby mogli ustawić je w naszym systemie, dzwoniąc do serwisu internetowego, a następnie uzyskać informacje o trasie i sposobie, w jaki pojazd się rozwija.

W przeszłości miałbym "przycięte" klasy DTO, które bardzo przypominają moje klasy domenowe, a klient utworzyłby RouteDto z tablicą StopDto (s) i zadzwoniłby do naszego webcastu CreateRoute, przekazując w RouteDto . Kiedy wysyłają zapytanie do naszego systemu, wywołując metodę GetRouteDetails, zwracałem do nich dokładnie te same obiekty. Jednym z atrakcyjnych aspektów CQRS jest to, że RouteDto może mieć wszystkie właściwości, które klient chce zapytać, ale nie mają żadnego ustawienia biznesowego podczas tworzenia trasy. Dlatego tworzę oddzielną klasę CreateRouteRequest, która jest przekazywana podczas wywoływania "polecenia" CreateRoute oraz klasy Route DTO, która jest zwracana jako wynik zapytania.

class Route{ 
    string Reference; 
    List<Stop> Stops; 
} 

Ale potrzebuję, aby mój klient podał mi szczegóły trasy i zatrzymania, gdy utworzą trasę. Jak widzę, mógłbym albo ...

Podaj moją klasę CreateRouteRequest a właściwość zatrzymania, która jest tablicą "czegoś" reprezentującą dane, które muszą podać o każdym przystanku - ale co nazywam tą klasą ? To nie jest Stop, ponieważ to właśnie nazywam listę DTO w moim DROGOWYM DROGU, ale nie lubię "CreateStopRequest". Zastanawiam się również, czy utknąłem w nastawieniu CRUD, myśląc w kategoriach informacji o szczegółach i prosząc klienta, aby tak myślał.

class CreateRouteRequest{ 
    string Reference; 
    ... 
    List<CreateStopRequest> Stops; 
} 

lub

Nazywają CreateRoute, a następnie wprowadź liczbę połączeń na metodzie AddStopToRoute. Czuję się nieco bardziej "behawioralny", ale stracę możliwość traktowania trasy, w tym jej przystanków, jako pojedynczego polecenia atomowego. Jeśli utworzą trasę, a następnie spróbują dodać zatrzymanie, które zawiedzie z powodu jakiegoś problemu z weryfikacją, będą mieli częściowo poprawną trasę.

Fakt, że nie mogę wymyślić dobrego imienia dla listy obiektów "StopCreationData", nad którymi pracuję w opcji 1, sprawia, że ​​zastanawiam się, czy czegoś brakuje.

Answer 1

Nie sądzę, że czegoś brakuje.

class CreateRouteRequest{ 
    string Reference; 
    ... 
    List<CreateStopRequest> Stops; 
} 

Wygląda dobrze dla mnie. Alternatywą użycia AddStopToRoute jest, moim zdaniem, niezbyt dobry pomysł, ponieważ tworzy on zbyt "rozmowny" interfejs, aby mógł być skutecznie wywoływany zdalnie.

Answer 2

Jednak korzystanie z żądania CreateRoute * * wydaje się wskazywać, że używasz wzorca żądania/odpowiedzi.

Jeśli rzeczywiście wysyłasz polecenia do serwera, serwer nie powinien zwracać obiektu/komunikatu odpowiedzi. Możesz po prostu pozwolić swojej usłudze wystawić metodę ExecuteCommand i wywołać ją, przekazując polecenie CreateRouteCommand.

Żądanie/odpowiedź nie jest właściwa CQRS IMHO.

Answer 3

Zdaję sobie sprawę, że jest to naprawdę stary post, ale ostatnio zmagałem się z podobnymi wzorami i czuję potrzebę wniesienia wkładu w ten wątek.Myślę, że jedną rzeczą, która powodowała uczucie, że OP odczuwają rozłączenie, było to, że zwoływali terminologię domeny na własny język operacyjny, zamiast dostosowywać swój projekt do domeny.

Odsunięcie jest w użyciu "create" jako czasownik. "Stworzenie", jak stwierdziłem, jest takie samo jak "wstawianie" w umyśle twórcy (myślę "CRUD") i często uciekamy się do tego czasownika, kiedy zaczynamy próbować na DDD, ponieważ wydaje się on mniej techniczny. Trasy, które zostały tutaj "stworzone", już istnieją. Są one po prostu rejestrowane w systemie. Wzdłuż tej samej linii, przystanki na trasie już istnieją, ale są również rejestrowane. Prosta zmiana w percepcji i brzmieniu, być może przy użyciu RecordRouteCommand z opcjonalną towarzyszącą kolekcją RecordStopOnRouteCommand, prawdopodobnie rozwiązałaby nieco zamieszanie. Zezwolenie na niezależne wysyłanie poleceń zatrzymania nagrywania zapewniłoby większą elastyczność w konstrukcji i wzmocnienie interfejsu API.

Zgadzam się również z Szymonem na prośbę kontra polecenie. To sformułowanie również prowadzi do myślenia sprzecznego z podejściem cqrs. Jeśli jest coś, czego nauczyła mnie DDD, to to, że słowa, których używamy w naszych projektach, są nie tylko ważne, mają ogromne znaczenie.