Servisní třídy

Měl jsem možnost vidět implementaci servisních tříd (servisa) z několika různých úhlů pohledu, v několika firmách. Obecně všechny tyto implementace se drží obecného principu – oddělit aplikační logiku od té doménové. Tak to má být (?). Pojďme si tento pojem popsat v souvislosti s DDD (Domain Driven Design).

Rozdělení servisních tříd

Důvod implementace servisních tříd popisuje Eric Evans ve své knize “Domain-Driven Design: Tackling Complexity in the Heart of Software“, tedy

Pokud specifický proces v doménové logice není přirozenou zodpovědností Entity nebo Value-Objectu, pridejte tuto operaci do doménoveho modelu jako samostatné rozhraní deklarované jako služba. Definujte rozhraní v pojmech jazyka modelu a ujistěte se, že jména jeho operací jsou součástí “obecně srozumizelného jazyka” (Ubiquitous Language). Vytvářejte servisy jako nestavové.

Jak jistě někomu již došlo, tak předpoklad z úvodu článku v tomto případě neplatí – servisní třídy jsou součastí implementace doménové logiky (to co se často označuje jako servisa je již konkretní implementace – tedy třída nikoliv rozhraní).
Entity a value-objekty si jistě zaslouží svůj zvláštní článek (na ten se již můžete těšit).

V pojmech DDD se obvykle bavíme o 3 typech servisních tříd

  • Aplikační – Operují nad skalárními typy a transformují je v typy doménové. Skalárním typem rozuměj typ kterému nerozumí doménový model (typicky třeba http request).
  • Doménové – Operují naopak jenom nad typy, které jsou součástí doménového modelu.
  • Strukturální – Jde o operace které jsou mimo dosah doménové logiky. Jde o operace splnují požadavky externích služeb – tedy například odesilání emailů, logování atd.

Aplikační servísní třídy

Doménové servisní třídy

Strukturální servisní třídy

Tento článek je publikován jako nekompletní, na jeho dokončení se již pracuje.