Domain Driven Design: Usługa Domeny, Usługa Aplikacji

^{(Jeśli nie masz ochoty czytać, na dole jest podsumowanie :-)}

Ja również zmagałem się z precyzyjną definicją usług aplikacyjnych. Chociaż odpowiedź Vijaya była bardzo pomocna w moim procesie myślenia miesiąc temu, doszedłem do wniosku, że nie zgadzam się z częścią tego.

Inne zasoby

Jest bardzo mało informacji o usługach aplikacyjnych. Tematy takie jak zagregowane korzenie, repozytoria i usługi domenowe są szeroko omawiane, ale usługi aplikacyjne są wymienione tylko krótko lub całkowicie pominięte.

Artykuły Jeffreya Palermo o cebuli Architektura (część one, dwa i trzy) to dobra lektura. Usługi aplikacji traktuje jako koncepcje na poziomie aplikacji , takie jak sesja użytkownika. Chociaż jest to bliższe mojemu rozumieniu usług aplikacyjnych, nadal nie jest to zgodne z moimi przemyśleniami na ten temat.

Moje myśli

Zacząłem myśleć o usługach aplikacyjnych jako o zależnościach dostarczanych przez aplikację. W takim przypadku aplikacja może być aplikacja desktopowa lub usługa WCF.

Domena

Czas na przykład. Zaczynasz od swojej domeny. Zaimplementowane są tutaj wszystkie podmioty i wszelkie usługi domenowe, które nie zależą od zasobów zewnętrznych. Wszelkie pojęcia domeny, które zależą od zasobów zewnętrznych, są definiowane przez interfejs. Oto możliwy układ rozwiązania (Nazwa projektu pogrubiona):

My Solution
- My.Product.Core (My.Product.dll)
  - DomainServices
      IExchangeRateService
    Product
    ProductFactory
    IProductRepository

Klasy Product i ProductFactory zostały zaimplementowane w Core assembly. {[7] } jest czymś, co prawdopodobnie wspierane przez bazę danych. Implementacja tego nie jest problemem domeny i dlatego jest definiowana przez interfejs.

Na razie skupimy się na IExchangeRateService. Logika biznesowa tej usługi jest implementowana przez zewnętrzny serwis internetowy. Jednak jego koncepcja jest nadal częścią domeny i jest reprezentowana przez ten interfejs.

Infrastruktura

Implementacja zewnętrznych zależności jest częścią infrastruktury aplikacji:

My Solution
+ My.Product.Core (My.Product.dll)
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - DomainServices
      XEExchangeRateService
    SqlServerProductRepository

XEExchangeRateService implementuje usługę domeny {[8] } komunikując się z xe.com . Ta implementacja może być używana przez twoje aplikacje, które wykorzystują twój model domeny, włączając w to zespół infrastruktury.

Zastosowanie

Zauważ, że nie wspomniałem jeszcze o usługach aplikacji. Przyjrzymy się im teraz. Załóżmy, że chcemy dostarczyć implementację IExchangeRateService, która używa pamięci podręcznej do szybkiego wyszukiwania. Zarys tej klasy dekoratorów może wyglądać następująco to.

public class CachingExchangeRateService : IExchangeRateService
{
    private IExchangeRateService service;
    private ICache cache;

    public CachingExchangeRateService(IExchangeRateService service, ICache cache)
    {
        this.service = service;
        this.cache = cache;
    }

    // Implementation that utilizes the provided service and cache.
}

Zauważ parametr ICache? Ta koncepcja nie jest częścią naszej domeny, więc nie jest usługą domenową. Jest to usługa aplikacji . Jest to zależność naszej infrastruktury, którą może zapewnić aplikacja. Przedstawmy aplikację, która to demonstruje:

My Solution
- My.Product.Core (My.Product.dll)
  - DomainServices
      IExchangeRateService
    Product
    ProductFactory
    IProductRepository
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
  - ApplicationServices
      ICache
  - DomainServices
      CachingExchangeRateService
      XEExchangeRateService
    SqlServerProductRepository
- My.Product.WcfService (My.Product.WcfService.dll)
  - ApplicationServices
      MemcachedCache
    IMyWcfService.cs
  + MyWcfService.svc
  + Web.config

To wszystko łączy się w aplikacji Tak:

// Set up all the dependencies and register them in the IoC container.
var service = new XEExchangeRateService();
var cache = new MemcachedCache();
var cachingService = new CachingExchangeRateService(service, cache);

ServiceLocator.For<IExchangeRateService>().Use(cachingService);

Podsumowanie

Kompletny wniosek składa się z trzech głównych warstwy:

• domena
• Infrastruktura
• zastosowanie

Warstwa domeny zawiera encje domen i autonomiczne Usługi domenowe. Wszelkie pojęcia domeny (obejmuje to usługi domeny, ale także repozytoria), które zależą od zasobów zewnętrznych, są definiowane przez interfejsy.

Warstwa infrastruktury zawiera implementację interfejsów z warstwy domeny. Wdrożenia te mogą wprowadzić nowe Nie-domeny zależności, które muszą być dostarczone aplikacji. Są to usługi aplikacji i są reprezentowane przez interfejsy.

Warstwa aplikacji zawiera implementację usług aplikacji. Warstwa aplikacji może również zawierać dodatkowe implementacje interfejsów domenowych, jeśli implementacje dostarczane przez warstwę infrastruktury nie są wystarczające.

Chociaż ta perspektywa może nie pasować do ogólnej definicji DDD usługi, oddziela domenę od aplikacji i pozwala na współdzielenie domeny (i infrastruktury) pomiędzy kilkoma aplikacjami.

Najlepszym zasobem, który pomógł mi zrozumieć różnicę między usługą aplikacyjną a usługą domenową, była implementacja Javy z przykładu ładunku Erica Evansa, znalezionego tutaj . Jeśli go nie pobierzesz, możesz sprawdzić wewnętrzne usługi RoutingService (usługa domeny) i BookingService, CargoInspectionService (które są usługami aplikacji).

Mój moment 'aha' został wywołany przez dwie rzeczy:

• Czytanie opisu usług w linku powyżej, dokładniej to zdanie:

Usługi domenowe są wyrażone w kategoriach wszechobecnego języka i typy domen, tzn. argumenty metody i wartości zwracane są odpowiednie klasy domen.

• czytanie tego posta na blogu , szczególnie tej części:

To, co znajduję dużą pomoc w oddzielaniu jabłek od pomarańczy, to myślenie w kategoriach przepływu pracy aplikacji. Cała logika dotycząca przepływ pracy aplikacji zazwyczaj kończy się jako usługi aplikacji uwzględnione w warstwie aplikacji, natomiast koncepcje z dziedziny które wydają się nie pasować, ponieważ obiekty modelowe tworzą jeden lub więcej Usługi Domenowe.

Usługa domeny jest rozszerzeniem domeny. Powinno być postrzegane tylko w kontekście danej domeny. To nie jest jakaś akcja użytkownika jak na przykład close account czy coś takiego. Usługa domeny pasuje tam, gdzie nie ma stanu. W przeciwnym razie byłby to obiekt domeny. Usługa domeny robi coś, co ma sens tylko wtedy, gdy jest wykonywana z innymi współpracownikami (obiekty domeny lub inne usługi). A to, że [[3]}ma sens jest odpowiedzialnością innego warstwa.

Usługa Aplikacji jest warstwą inicjującą i nadzorującą interakcję między obiektami domeny i usługami. Przepływ jest zazwyczaj taki: pobrać obiekt domeny (lub obiekty) z repozytorium, wykonać akcję i umieścić ją (je) tam (lub nie). Może zrobić więcej - na przykład może sprawdzić, czy obiekt domeny istnieje, czy nie i odpowiednio rzucać wyjątki. Pozwala więc użytkownikowi na interakcję z aplikacją (i prawdopodobnie stąd pochodzi jej nazwa from) - poprzez manipulowanie obiektami i usługami domeny. Usługi aplikacyjne powinny zasadniczo reprezentować wszystkie możliwe przypadki użycia . Prawdopodobnie najlepszą rzeczą, jaką możesz zrobić, zanim pomyślisz o domenie, jest stworzenie interfejsów usług aplikacji, co da ci znacznie lepszy wgląd w to, co naprawdę próbujesz zrobić. Posiadanie takiej wiedzy pozwala skupić się na domenie.

Repozytoria mogą być ogólnie rzecz biorąc wstrzykiwane do usług domenowych, ale jest to raczej rzadki scenariusz. Informatyka jest warstwą aplikacji, która robi to przez większość czasu.

Z Czerwonej Księgi (Implementing Domain Driven Design, autorstwa Vaughna Vernona), Tak rozumiem pojęcia:

Obiekty domeny (encje i obiekty wartości ) hermetyzują zachowanie wymagane przez (Pod)domenę, czyniąc ją naturalną, wyrazistą i zrozumiałą.

Usługi domeny zawierają takie zachowania, które nie mieszczą się w obiekcie domeny . Na przykład biblioteka książek użyczająca Book Client (z odpowiednie zmiany Inventory) mogą to zrobić z usługi domeny.

Usługi aplikacyjne obsługują przepływ przypadków użycia, w tym wszelkie dodatkowe obawy potrzebne na szczycie domeny. często ujawnia takie metody za pośrednictwem swojego API, do wykorzystania przez klientów zewnętrznych. Aby bazować na naszym poprzednim przykładzie, nasza usługa aplikacji może ujawnić metodę LendBookToClient(Guid bookGuid, Guid clientGuid), która:

• odzyskuje Client.
• potwierdza jego uprawnienia. (zauważ jak zachowaliśmy nasz model domeny bez obaw o bezpieczeństwo / zarządzanie użytkownikami. Takie zanieczyszczenie może prowadzić do wielu problemów. Zamiast tego spełniamy ten wymóg techniczny tutaj, w naszym serwisie aplikacji.)
• odzyskuje Book.
Domena ta jest używana do obsługi domen (przekazujących Client i Book), Aby Obsługiwać rzeczywistą logikę domeny wypożyczenia książki klientowi. Na przykład, wyobrażam sobie, że potwierdzenie dostępności książki jest zdecydowanie częścią domeny logika.

Usługa aplikacji powinna mieć bardzo prosty przepływ. Złożone przepływy usług aplikacji często wskazują, że logika domeny wyciekła z domeny.

Jak mamy nadzieję zobaczyć, model domeny pozostaje bardzoczysty w ten sposób i jest łatwy do zrozumienia i omówienia z ekspertami od domen, ponieważ zawiera tylko własne, rzeczywiste problemy biznesowe. przepływ aplikacji , z drugiej strony, jest również dużo łatwiejszy w zarządzaniu, ponieważ jest zwolniony z obaw dotyczących domeny i staje się zwięzły i prosty.

Domain Services: metody, które tak naprawdę nie pasują do jednego podmiotu lub wymagają dostępu do repozytorium są zawarte w domenie usługi. Warstwa usługi domeny może również zawierać logikę domeny własnej i jest tak samo częścią modelu domeny jak podmioty i wartość obiektów.

Usługi aplikacji: usługa Aplikacji jest cienką warstwą, która znajduje się nad modelem domeny i koordynuje aplikację aktywność. Nie zawiera logiki biznesowej i nie posiada stan wszelkich podmiotów; może jednak przechowywać stan przedsiębiorstwa transakcja workflow. Korzystasz z usługi aplikacji w celu zapewnienia interfejsu API do modelu domeny za pomocą wzorca wiadomości Request-Reply.

Millett, C (2010). Professional ASP.NET wzorce projektowe. Wydawnictwo Wiley. 92.