O usługach

Zostałem niedawno zapytany, dlaczego w projekcie DDDSample.NET projekt “Application” nazywa się właśnie tak, a nie “Domain Services”. Zwróciło to moją uwagę na całkiem spory problem nazewnictwa związanego z DDD oraz ogólnie z architekturami. Jednym ze źródeł problemu zdaje się być niesamowicie przeładowane znaczeniowo słowo “usługa”. Ale po kolei…

Wspomniany projekt “Application” zawiera fasadę Modelu Domeny udostępniającą operacje biznesowe realizowane za pomocą tegoż modelu. Te operacje to coś w rodzaju transaction script-ów operujących na obiektach domeny. Nazwę zaczerpnąłem oczywiście wprost z Java-owego oryginału, którego dokumentacja tak opisuje ten element architektury:

The application layer is responsible for driving the workflow of the application, matching the use cases at hand. These operatios are interface-independent and can be both synchronous or message-driven. This layer is well suited for spanning transactions, high-level logging and security.

The application layer is thin in terms of domain logic – it merely coordinates the domain layer objects to perform the actual work.

Przyznam szczerze, że nazwa “Application” nie jest najszczęśliwsza na świecie, bo tak na dobrą sprawę, nie mówi nic o przeznaczeniu tej warstwy. Można ją znaleźć także w innych przykładach, np. w architekturze cebulowej Jeffreya Palermo. Różnica polega jednak na tym, że u Palermo nazwa brzmi “Application Services”, co niesie już ze sobą jakieś znaczenie — mamy do czynienia z usługami.

No właśnie. Dlaczego pisałem na wstępie, że winne jest słowo “usługa”? Ponieważ tak naprawdę ja najchętniej z “Application Services” zostawiłbym “Services” jako nazwę mojej warstwy. Zauważcie, że pasuje ona o wiele lepiej pasuje do przytoczonego opisu. Niestety usługi występują już w tylu kontekstach w naszej terminologii, że wprowadzenie kolejnych “usług” byłoby niewskazane.

Być może lepiej byłoby w ogóle zrezygnować z terminologii wywodzącej się z “Application Services”? Można się odwołać np. do tego, że warstwa ta implementuje przypadki użycia i nazwać ją “Use Cases”. Albo, podchodząc do problemu od strony technicznej, zauważyć że jest to implementacja wzorca fasady — “Model Facade”. A jak Wy nazywacie projekty takiego rodzaju w swoich architekturach?

Druga część pytania dotyczy domain services — usług modelu domeny. Wydaje się, że jest jeszcze wiele wątpliwości związanych z usługami w Domain Driven Design. Moje rozumienie tego termin jest następujące.

Usługi modelu domeny pozwalają wyrazić operacje, które nie mają naturalnie przypisanego obiektu wykonującego je lub są realizowane przez obiekty zewnętrzne w stosunku do modelu. Na przykład IPricingService to usługa zwracająca ceny produktów na podstawie danych uzyskanych z innego systemu za pośrednictwem webserwisu. Na poziomie modelu reprezentowana jest przez interfejs, aby nie uzależniać go od szczegółów implementacyjnych.

Osoba, która zadała mi pytanie rozumiała usługi domenowe jako sposób na wykonanie pewnych bardziej skomplikowanych operacji biznesowych poprzez orkiestrację wywołań na obiektach modelu, czyli… dokładnie to, co u mnie kryje znajduje się w warstwie “Application”. Podobne opinie znalazłem też na kilku znanych blogach, np. tu. Cóż, nie zgadzam się z takim podejściem. Nie widzę sensu, aby definiować takie byty. Co więcej, usługi domenowe w takim znaczeniu miałyby bardzo niebezpieczną tendencję to wysysania logiki biznesowej z obiektów modelu.

Podsumowując, w dużym skrócie i uproszczeniu:

• Następnym razem napewno nazwę swoją warstwę “Application” inaczej. Skłaniam się ku “Use Cases”.
• Usługi domenowe mogą reprezentować albo operacje nie posiadające wykonawcy (algorytmy), albo być abstrakcją dla synchronicznych usług implementowanych na zewnątrz. Oba przypadki powinny być bardzo rzadkie.