Jak wybierać między używaniem zdarzenia domeny lub zezwalaniem warstwie aplikacji na koordynowanie wszystkiego

Swoje pierwsze kroki stawiam na projektowanie oparte na domenie, kupiłem niebieską książkę i wszystko inne, i widzę trzy sposoby na wdrożenie określonego rozwiązania. Dla przypomnienia: nie używam CQRS ani Event Sourcing.

Załóżmy, że żądanie użytkownika wchodzi do warstwy usługi aplikacji. Logika biznesowa dla tego żądania jest (z dowolnego powodu) podzielona na metodę w encji i metodę w usłudze domeny. Jak powinienem wywoływać te metody?

Do tej pory zebrałem opcje:

• Pozwól usłudze aplikacji wywoływać obie metody
• Użyj metody wstrzyknięcia / podwójnej wysyłki, aby wstrzyknąć usługę domeny do encji, pozwalając encji zrobić to, a następnie pozwolić wywołać metodę usługi domeny (lub odwrotnie, pozwalając usłudze domeny wywołać metodę dla encji)
• Podnieś zdarzenie domeny w metodzie encji, której moduł obsługi wywołuje usługę domeny. (Rodzaje wydarzeń w domenie, o których mówię, to: http://www.udidahan.com/2009/06/14/domain-events-salvation/ )

Myślę, że wszystkie są realne, ale nie jestem w stanie wybierać między nimi. Myślałem o tym od dawna i doszedłem do punktu, w którym nie widzę już różnic semantycznych między tymi trzema. Czy znasz jakieś wskazówki, kiedy z czego korzystać?

Pozwól usłudze aplikacji wywoływać obie metody

Usługa aplikacji jest zazwyczaj świetnym miejscem do rozpoczęcia tego procesu, jednak zawsze należy starać się zmieniać zachowanie tak blisko jednostki, jak to możliwe. Usługa aplikacji odgrywa rolę koordynującą i ustawia etap wykonywania zachowania domeny i jako taka zapewnia wszystkie wymagane zależności. Jednak w miarę możliwości powinien on przekazać zachowanie modelowi domeny.

Użyj metody wstrzyknięcia / podwójnej wysyłki, aby wstrzyknąć usługę domeny do encji, pozwalając encji zrobić to, a następnie pozwolić wywołać metodę usługi domeny (lub odwrotnie, pozwalając usłudze domeny wywołać metodę dla encji)

Jest to lepsze podejście, ponieważ większa część zachowania jest delegowana do encji lub usługi domenowej. Najbardziej niezwiązanym ze sobą sposobem realizacji tego jest wyrażenie przez jednostkę zależności od usługi jako parametru metody zapewniającej dane zachowanie.

Podnieś zdarzenie domeny w metodzie encji, której moduł obsługi wywołuje usługę domeny.

Wzorzec zdarzeń w domenie, jak wyjaśnił Udi, a także sam Evans, jest dość wszechstronny i może być stosowany w różnych scenariuszach. Jest jednak kilka komplikacji. Po pierwsze, musisz upewnić się, że masz odpowiednie zakresy w wydawcy zdarzeń domeny. W większości przypadków programy obsługi zdarzeń w domenie będą zależne, a jeśli używasz kontenera IoC, musisz upewnić się, że wstrzyknięto odpowiednie instancje. Na przykład w aplikacji sieci Web[ThreadStatic]atrybut jest problematyczny przy określaniu zakresu. Inną złożonością są granice transkrypcji. Musisz wziąć pod uwagę transakcje, ponieważ jeśli jednostka wywoła zdarzenie domeny, ale kolejne zatwierdzenie do bazy danych nie powiedzie się, wszystkie programy obsługi zdarzeń domeny będą musiały mieć możliwość wycofania, w przeciwnym razie spowoduje to nieprawidłowe zdarzenie. Jeśli jednak znasz te zasady, zdarzenia domeny są doskonałym wzorcem do enkapsulacji logiki domeny w samych bytach.

Różnica między podejściem 2 i 3 zależy od przypadku użycia. Zdarzenie w domenie ma zastosowanie, gdy chcesz wywołać dodatkowe zachowania w odpowiedzi na zdarzenie, które jest w czasie przeszłym . Jest to ważne ograniczenie, ponieważ moduł obsługi zdarzeń domeny nie może wpływać na zachowanie encji. Z drugiej strony, w przypadku podejścia 2, wstrzykiwana usługa może potencjalnie wpływać na zachowanie, ponieważ jest zadeklarowana jako zależność dla tego konkretnego zachowania.