Všudypřítomný jazyk

Doménou řízený návrh (DDD) není nové téma (Eric Evans tento koncept formalizoval před více než deseti lety). Je však zvláštní, jak dodnes základní koncepty na toto téma vzbuzují zájem zejména v komunitách .NET. Ještě podivnější je, jak jsou tytéž koncepty nesprávně interpretovány.

Základ DDD spočívá v konceptu všudypřítomného jazyka. Nespočívá v určení toho, co je entita, hodnotový objekt, agregát, služba nebo úložiště.

Máme dojem, že každý, kdo začne studovat DDD, si přečte prvních pár stránek knihy o Evansovi nebo Vernonovi a rychle přeskočí rovnou na stránky, které popisují vzory.

Často mluvíme s lidmi z IT, kteří si myslí, že mít definovaný všudypřítomný jazyk znamená, že názvy tříd a vlastností, psané programátory, odpovídají slovníku doménových expertů. To je však hrubé zjednodušení.

Abychom pochopili význam všudypřítomného jazyka, začněme s níže uvedenou „entitou“:

public class Employee{ public string Id { get; set; } public string Name { get; set; } public string Cpf { get; set; } public decimal Salary { get; set; }}

Tady je vynikající příklad anemické implementace! Ale než budete číst dál, zkuste přijít na to, proč.

Při každodenní práci, když používáme tento příklad, slýcháme návrhy, že tato třída postrádá chování (Což je správně!). Když se však zeptáme, jaké by takové „chování“ mělo být, zjistíme, že lidé opakují obecné argumenty (od lidí, kteří tuto myšlenku také „nepochopili“) a nedokážou určit, co je špatně!“

Jeden z nejčastějších argumentů je, že nastavovače vlastností by měly být soukromé. Místo nich bychom měli mít metody „DefineXXX“, které by implementovaly validace. Tato myšlenka nedává smysl, protože účelem setterů je právě nastavování hodnot vlastností a nebyl by problém v nich implementovat validační logiku.

Metody entity by měly upřesňovat motivaci pro změny jejího stavu. Také musí existovat alespoň jeden konstruktor, který je schopen instancovat entitu od začátku ve validním stavu.

Není neobvyklé, že se setkáváme s implementacemi tříd s vlastnostmi, které například kontrolují, zda hodnota, kterou se snažíme nastavit, není nulová, i když tytéž vlastnosti mají jako výchozí hodnotu null. Jaká je zde logika?“

Podívejte se na další příklad anemické třídy:

public class Customer { public string Name { get; private set; } public string Email { get; private set; } public DateTime BirthDate { get; private set; } public Customer(Guid id, string name, string email, DateTime birthDate) { Id = id; Name = name; Email = email; BirthDate = birthDate; } }

Ve výše uvedené třídě máme typický „záznam“ pro funkční implementaci. V objektově orientovaném jazyce to však není entita.

Tato myšlenka by dokonce dávala smysl v čistě funkcionálním jazyce, kde je „entita“ pojmově rozprostřena v různých funkcích, které definují chování, ale v jazyce C# nedává vůbec žádný smysl.

Zkusíme druhou verzi pro třídu Zaměstnanec:

public class Employee{ public string Id { get; private set; } public string Name { get; private set; } public string Cpf { get; private set; } public decimal Salary { get; private set; } public Employee(string name, string cpf) { //.. } public void RaiseSalary(decimal amount) { //.. }}

Tentokrát je entita méně anemická. Motivace, které vedou ke změně hodnoty vlastnosti, jsou přece jen zřejmé. Všimněte si, že i hodnota psaní testů se stává zřetelnější.

V každém případě máme stále problémy. Pojmenovali jsme metodu „RaiseSalary“, nicméně takto doménoví experti tuto operaci nepopisují. Jediný způsob, jak definovat skutečné důvody pro změnu hodnot vlastností, je rozhovor s těmito experty.

K zamyšlení…

Identifikace a implementace všudypřítomného jazyka neslouží jen k definování názvů tříd nebo vlastností. Všudypřítomný jazyk je třeba odhalit především v motivacích pro explicitní změny stavu našich entit.

Pochopení všudypřítomného jazyka je mnohem důležitější než naučit se standardy. Bez skutečné znalosti domény je hodnota návrhových vzorů nulová.

Nejdříve se naučte to nejdůležitější. Věnujte čas a úsilí tomu, abyste dobře porozuměli doméně a osvojili si její všudypřítomný jazyk. Pak může mít smysl uvažovat i o spojení DDD s pokročilejšími technickými koncepty.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.