Czy ktoś może wyjaśnić różnicę między domeną a usługami aplikacji, podając kilka przykładów? A jeśli usługa jest usługą domenową, czy umieściłbym rzeczywistą implementację tej usługi w zestawie domen, a jeśli tak, czy wstrzykiwałbym również repozytoria do tej usługi domenowej? Niektóre informacje byłyby naprawdę pomocne.
Odpowiedzi:
Usługi są w 3 smakach: Usługi Domain , Application Services i infrastruktury usług .
Utrzymywanie usług domenowych wraz z obiektami domeny jest rozsądne - wszystkie skupiają się na logice domeny. I tak, możesz wstrzykiwać repozytoria do swoich usług.
Usługi aplikacji zazwyczaj będą używać zarówno usług domenowych, jak i repozytoriów do obsługi zewnętrznych żądań.
Mam nadzieję, że to pomaga!
(Jeśli nie masz ochoty czytać, na dole jest podsumowanie :-)
Ja również miałem problemy z precyzyjną definicją usług aplikacyjnych. Chociaż odpowiedź Vijay była bardzo pomocna w moim procesie myślenia miesiąc temu, nie zgadzam się z częścią tego.
Jest bardzo mało informacji o usługach aplikacyjnych. Tematy takie jak zagregowane katalogi główne, repozytoria i usługi domenowe są szeroko dyskutowane, ale usługi aplikacyjne są wspomniane tylko krótko lub całkowicie pominięte.
Artykuł w MSDN Magazine Wprowadzenie do projektowania opartego na domenie opisuje usługi aplikacji jako sposób na transformację i / lub udostępnienie modelu domeny klientom zewnętrznym, np. Jako usługa WCF. W ten sposób Vijay opisuje również usługi aplikacji. Z tego punktu widzenia usługi aplikacji są interfejsem do Twojej domeny .
Artykuły Jeffrey Palermo na temat architektury cebuli (część pierwsza , druga i trzecia ) są dobrą lekturą. Traktuje usługi aplikacji jako pojęcia na poziomie aplikacji , takie jak sesja użytkownika. Chociaż jest to bliższe mojemu zrozumieniu usług aplikacyjnych, nadal nie jest to zgodne z moimi przemyśleniami na ten temat.
Zacząłem myśleć o usługach aplikacyjnych jako o zależnościach zapewnianych przez aplikację . W takim przypadku aplikacja może być aplikacją komputerową lub usługą WCF.
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 koncepcje domen zależne od zasobów zewnętrznych są definiowane przez interfejs. Oto możliwy układ rozwiązania (pogrubiona nazwa projektu):
Moje rozwiązanie
- My.Product.Core (My.Product.dll)
- DomainServices
IExchangeRateService
Produkt
ProductFactory
IProductRepository
ProductI ProductFactoryzajęcia zostały wdrożone w zespole rdzenia. Jest IProductRepositoryto coś, co prawdopodobnie jest wspierane przez bazę danych. Implementacja tego nie jest domeną i dlatego jest zdefiniowana przez interfejs.
Na razie skupimy się na IExchangeRateService. Logika biznesowa tej usługi jest realizowana przez zewnętrzną usługę internetową. Jednak jego koncepcja jest nadal częścią domeny i jest reprezentowana przez ten interfejs.
Implementacja zewnętrznych zależności jest częścią infrastruktury aplikacji:
Moje rozwiązanie
+ My.Product.Core (My.Product.dll)
- My.Product.Infrastructure (My.Product.Infrastructure.dll)
- DomainServices
XEExchangeRateService
SqlServerProductRepository
XEExchangeRateServiceimplementuje IExchangeRateServiceusługę domenową komunikując się z xe.com . Ta implementacja może być używana przez aplikacje korzystające z modelu domeny, włączając zestaw infrastruktury.
Pamiętaj, że nie wspomniałem jeszcze o usługach aplikacyjnych. Przyjrzymy się teraz tym. Powiedzmy, że chcemy zapewnić IExchangeRateServiceimplementację, która wykorzystuje pamięć podręczną do szybkiego wyszukiwania. Zarys tej klasy dekoratora może wyglądać tak.
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ż ICacheparametr? Ta koncepcja nie jest częścią naszej domeny, więc nie jest to usługa domenowa. To usługa aplikacji . Jest to zależność naszej infrastruktury, którą może zapewnić aplikacja. Przedstawiamy aplikację, która to pokazuje:
Moje rozwiązanie
- My.Product.Core (My.Product.dll)
- DomainServices
IExchangeRateService
Produkt
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
Wszystko to łączy się w takiej aplikacji:
// 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);
Kompletna aplikacja składa się z trzech głównych warstw:
Warstwa domeny zawiera jednostki domeny i autonomiczne usługi domenowe. Wszelkie koncepcje domen (w tym usługi domenowe, 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. Implementacje te mogą wprowadzać nowe zależności niebędące domenami, 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 domen, jeśli implementacje dostarczone przez warstwę infrastruktury nie są wystarczające.
Chociaż ta perspektywa może nie pasować do ogólnej definicji usług DDD, oddziela ona domenę od aplikacji i umożliwia współdzielenie zestawu domeny (i infrastruktury) między kilkoma aplikacjami.
IExchangeRateServiceinterfejs? Jest to koncepcja domeny, tj. Coś, co jest zawarte we wszechobecnym języku klienta. Inne części domeny mogą zależeć od tej usługi, dlatego jej interfejs jest zdefiniowany w warstwie domeny. Ponieważ jednak jego implementacja obejmuje zewnętrzną usługę internetową, klasa implementująca znajduje się w warstwie infrastruktury. W ten sposób warstwa domeny zajmuje się tylko logiką biznesową.
ExchangeRateinstancja, która zawiera walutę bazową, walutę przeciwną i wartość kursu wymiany między tymi dwiema walutami. Te ściśle powiązane wartości reprezentują koncepcję „kursu wymiany” z domeny, więc żyją w warstwie domeny. Chociaż może wydawać się prostym DTO, w DDD nazywa się go Obiektem Wartości i może zawierać dodatkową logikę biznesową do porównywania lub przekształcania instancji.
Najlepszym zasobem, który pomógł mi zrozumieć różnicę między usługą aplikacji a usługą domenową, była implementacja java przykładu ładunku Erica Evansa, znaleziona tutaj . Jeśli go nie załadujesz, możesz sprawdzić elementy wewnętrzne usługi RoutingService (usługa domenowa) oraz BookingService, CargoInspectionService (które są usługami aplikacji).
Moja chwila „aha” została wywołana przez dwie rzeczy:
Czytanie opisu Usług w powyższym linku, a dokładniej to zdanie:
Usługi domenowe wyrażane są w kategoriach wszechobecnego języka i typów domen, tj. Argumenty metody i zwracane wartości są właściwymi klasami domen.
Czytanie tego posta na blogu , szczególnie tej części:
To, co znajduję dużą pomoc w oddzielaniu jabłek od pomarańczy, polega na przepływie pracy aplikacji. Cała logika dotycząca przepływu pracy aplikacji zazwyczaj kończy się na uwzględnieniu usług aplikacji w warstwie aplikacji, podczas gdy koncepcje z domeny, które wydają się nie pasować jako obiekty modelu, ostatecznie tworzą jedną lub więcej usług domeny.
Usługa domenowa jest rozszerzeniem domeny. Powinno być postrzegane tylko w kontekście domeny. To nie jest żadna akcja użytkownika, jak na przykład zamknięcie konta lub 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 w przypadku współpracy z innymi współpracownikami (obiektami domeny lub innymi usługami). I to sens ma odpowiedzialność innej warstwy.
Usługa aplikacji to ta warstwa, która inicjuje i nadzoruje interakcję między obiektami i usługami domeny. Przebieg jest ogólnie taki: pobierz obiekt domeny (lub obiekty) z repozytorium, wykonaj akcję i umieść go (je) z powrotem (lub nie). Może zrobić więcej - na przykład może sprawdzić, czy obiekt domeny istnieje, czy nie, i odpowiednio zgłosić wyjątki. Pozwala to użytkownikowi na interakcję z aplikacją (i prawdopodobnie stąd pochodzi jej nazwa) - poprzez manipulowanie obiektami i usługami domeny. Usługi aplikacji powinny ogólnie reprezentować wszystkie możliwe przypadki użycia. Prawdopodobnie najlepszą rzeczą, jaką możesz zrobić, zanim pomyślisz o domenie, jest stworzenie interfejsów usługi aplikacji, co da ci znacznie lepszy wgląd w to, co naprawdę chcesz zrobić. Posiadanie takiej wiedzy pozwala skupić się na domenie.
Zasadniczo repozytoria można wstrzykiwać do usług domenowych, ale jest to raczej rzadki scenariusz. Jednak to warstwa aplikacji robi to przez większość czasu.
Z Czerwonej Księgi (Implementacja projektu opartego na domenie, autorstwa Vaughna Vernona) w ten sposób rozumiem te pojęcia:
Obiekty domeny ( byty i obiekty wartości ) zawierają zachowanie wymagane przez (pod) domenę, dzięki czemu jest ona naturalna, ekspresyjna i zrozumiała.
Usługi domenowe zawierają takie zachowania, które nie mieszczą się w jednym obiekcie domeny. Na przykład, biblioteka książka użyczenia BookDo Client(z odpowiednimi Inventoryzmianami) może zrobić z usługi domeny.
Usługi aplikacyjne obsługiwać przepływ przypadkach stosowania, w tym dodatkowych problemów potrzebnych na szczycie domeny. Często ujawnia takie metody za pośrednictwem interfejsu API do użytku przez klientów zewnętrznych. W oparciu o nasz poprzedni przykład nasza usługa aplikacji może ujawnić metodę, LendBookToClient(Guid bookGuid, Guid clientGuid)która:
Client.Book.Clienti Book), aby obsłużyć rzeczywistą logikę domeny pożyczania książki klientowi. Na przykład wyobrażam sobie, że potwierdzenie dostępności książki jest zdecydowanie częścią logiki domeny.Usługa aplikacji powinna zasadniczo mieć bardzo prosty przepływ. Złożone przepływy usług aplikacyjnych często wskazują, że logika domeny wyciekła z domeny.
Jak widać, model domeny pozostaje w ten sposób bardzo czysty i jest łatwy do zrozumienia i dyskusji z ekspertami w tej dziedzinie, ponieważ zawiera on tylko własne, rzeczywiste obawy biznesowe. Z drugiej strony przepływ aplikacji jest również znacznie łatwiejszy w zarządzaniu, ponieważ nie ma obaw związanych z domeną, staje się zwięzły i prosty.
Usługi domenowe: metody, które tak naprawdę nie pasują do jednego obiektu lub wymagają dostępu do repozytorium, są zawarte w usługach domenowych. Warstwa usług domenowych może również zawierać własną logikę domeny i jest tak samo częścią modelu domeny, jak jednostki i obiekty wartości.
Usługi aplikacji: usługa aplikacji to cienka warstwa, która znajduje się nad modelem domeny i koordynuje działanie aplikacji. Nie zawiera logiki biznesowej i nie utrzymuje stanu żadnych podmiotów; może jednak przechowywać stan transakcji biznesowej. Usługa aplikacji służy do udostępniania interfejsu API w modelu domeny przy użyciu wzorca komunikatów Żądanie-Odpowiedź.
Millett, C (2010). Profesjonalne wzorce projektowe ASP.NET. Wiley Publishing. 92
Usługi domenowe : usługa wyrażająca logikę biznesową, która nie jest częścią żadnego głównego katalogu agregującego.
Masz 2 agregaty:
Product który zawiera nazwę i cenę.Purchase który zawiera datę zakupu, listę produktów zamówionych wraz z ilością i ceną produktu w tym czasie oraz metodę płatności.Checkout nie jest częścią żadnego z tych dwóch modeli i jest koncepcją w Twojej firmie.
Checkoutmożna utworzyć jako usługę domenową, która pobiera wszystkie produkty i oblicza całkowitą cenę, płaci całkowitą kwotę, dzwoniąc do innej usługi domenowej PaymentServicez częścią implementacyjną infrastruktury i przekształcając ją w Purchase.Usługi aplikacji : usługa, która „koordynuje” lub ćwiczy metody domenowe. Może to być tak proste, jak sam kontroler.
Jest to miejsce, w którym zwykle robisz:
public String createProduct(...some attributes) {
if (productRepo.getByName(name) != null) {
throw new Exception();
}
productId = productRepository.nextIdentity();
product = new Product(productId, ...some attributes);
productRepository.save(product);
return productId.value();
// or Product itself
// or just void if you dont care about result
}
public void renameProduct(productId, newName) {
product = productRepo.getById(productId);
product.rename(newName);
productRepo.save(product);
}
Możesz tutaj dokonać weryfikacji, np. Sprawdzając, czy a Productjest unikalny. O ile Productbycie niepowtarzalnym nie jest niezmiennikiem, powinno to być częścią Usługi Domeny, którą można wywołać, UniqueProductCheckerponieważ nie może być częścią Productklasy i wchodzi w interakcje z wieloma Agregatami.
Oto pełny przykład projektu DDD: https://github.com/VaughnVernon/IDDD_Samples
Można znaleźć wiele przykładów usługi aplikacji i kilka usług domenowych
Pomyśl o usłudze domenowej jako obiekcie, który implementuje logikę biznesową lub logikę związaną z regułami biznesowymi na obiektach domeny, a ta logika jest trudna do dopasowania do tych samych obiektów domeny, a także nie powoduje zmiany stanu usługi domeny (usługa domeny jest obiektem bez „stan” lub lepiej bez stanu o znaczeniu biznesowym), ale ostatecznie zmień stan tylko obiektów domeny, na których działa.
Podczas gdy usługa aplikacji implementuje logikę na poziomie aplikacji jako interakcję użytkownika, sprawdzanie poprawności danych wejściowych, logikę niezwiązaną z biznesem, ale z innymi problemami: uwierzytelnianiem, bezpieczeństwem, wysyłaniem e-maili itd., Ograniczając się do korzystania z usług udostępnianych przez obiekty domeny.
Przykładem tego może być następujący scenariusz, który ma na celu jedynie wyjaśnienie celu: musimy wdrożyć bardzo małą aplikację domotyczną, która wykonuje prostą operację, tj. „Włącz światła, gdy ktoś otworzy drzwi pokoju w domu, aby wejść i wyłącz światło, gdy zamyka drzwi wychodzące z pokoju ".
Upraszczając wiele, bierzemy pod uwagę tylko 2 jednostki domeny: Doori Lampkażdy z nich ma 2 stany, odpowiednio open/closedi on/off, i konkretne metody operowania na nich zmianami stanu.
W tym przypadku potrzebujemy usługi domenowej, która wykonuje konkretną operację włączania światła, gdy ktoś otwiera drzwi z zewnątrz, aby wejść do pokoju, ponieważ drzwi i obiekty lampy nie mogą zastosować tej logiki w sposób, który uważamy za odpowiedni do ich natury .
Możemy nazwać nasze usługi domeny jak DomoticDomainServicei wdrożyć 2 sposoby: OpenTheDoorAndTurnOnTheLighta CloseTheDoorAndTurnOffTheLightte 2 metody respectevely zmienić stan obu obiektów Doori Lampdo open/ona closed/off.
Stan wejścia lub wyjścia z pokoju, którego nie ma w obiekcie usługi domeny ani w obiektach domeny, ale zostanie zaimplementowany jako prosta interakcja użytkownika przez usługę aplikacji, którą możemy wywołać HouseService, która implementuje niektóre programy obsługi zdarzeń jako onOpenRoom1DoorToEnteri onCloseRoom1DoorToExittak dalej dla każdego pokoju (jest to tylko przykład wyjaśnienia celu ..) , które będą odpowiednio dotyczyły metod usług domenowych wywołań w celu wykonania obserwowanego zachowania (nie wzięliśmy pod uwagę jednostki, Roomponieważ jest to tylko przykład) .
Ten przykład, jak na razie będący dobrze zaprojektowaną aplikacją w świecie rzeczywistym, ma jedyny cel (jak powiedziano więcej), aby wyjaśnić, czym jest Usługa Domeny i czym różni się od Usługi Aplikacji, mam nadzieję, że będzie ona jasna i użyteczna.