Wszechobecny język

2 lata temu powstała książka 'Domain Driven Design' Erica Evansa. Kto nie czytał - polecam. Książkę można podsumować jednym zdaniem: Object-Oriented design done right. Treść nie powinna zaskoczyć żadnego programisty OO, ale i tak warto przeczytać, ponieważ dość zgrabnie podsumowuje podstawowe zasady projektowania aplikacji obiektowych. Składa się ona z trzech podstawowych części:
- Wszechobecny Język (Ubiquitous Language)
- Model-Driven Design
- Zachowywanie spójności modelu

Zamieszczam tu telegraficzny skrót tej książki, bo uważam ją za ważny element edukacji programistycznej.

Tak więc w tym poście podstawowy element DDD:

Wszechobecny Język to idea jednego wspólnego języka dla dziedziny (tak jak rozumie ją użytkownik/klient/biznes), aplikacji i języka komunikacji programistów. Brzmi dość logicznie - tych samych nazw używamy w rozmowie z biznesem (klientem, analitykami, ekspertami, itp. itd...), w kodzie i w zespole - to ułatwia komunikację (najwięcej problemów w projektach leży właśnie tu) i zmniejsza ryzyko nieporozumień.
Wszystko świetnie brzmi jak się ma klienta anglojęzycznego. W większości projektów mamy jednak Polskojęzycznego klienta. Polskie (czy generalnie nieangielskie) nazwy w kodzie (zmienne, metody, komentarze) uważam za zły pomysł ze względu na 2 rzeczy - globalność naszego zawodu (dziś kod piszesz ty, jutro firma w Indiach albo Chinach) oraz czytelność (findFirmaByUlica czyta się strasznie) . Jestem więc zwolennikiem tłumaczeń na angielski, choć czasami nie jest to możliwe (NIP, Pesel itp. są kiepsko tłumaczalne).
Wszechobecny język to również idea sposobu komunikacji z biznesem - używanie ich języka to nie wszystko. Trzeba by dodać jeszcze nieużywanie naszego. Jak ekspert od ubezpieczeń mów:

"Chciałbym, żeby się dało usuwać polisy."

a ty zapytasz go:

"A wystarczy jak usunę rekord z tabelki? Czy mam dorzucać nowy z markerem, że usunięte?"

To boję się, że jest szansa na poziomie 50%, że on nie wie o czym mówisz, a 90% że nie wie po co ten marker i jakie są tego następstwa takiej decyzji. Nie mówiąc o tym, że decydowanie na tym etapie o implementacji jest pewnie przedwczesne. Powinieneś więc pewnie raczej zapytać np.:

"A czy potrzebujecie zachowywać kompletną historię dla każdej polisy?"
"A co z ochroną danych osobowych?"

Tak więc to właśnie od programisty/projektanta oczekuje się mówienia językiem biznesu i projektowanie w tych właśnie terminach a nie od analityka / eksperta znajomości nomenklatury i idei technologicznych. Dzięki temu dobrze napisany kod (nawet w Javie) może być czytelny prawie jak specyfikacja funkcjonalności i jakby się uprzeć, to można go pokazać ekspertowi i zapytać czy o to chodzi.
Poniżej kod z jednego z projektów które pisałem.

class Contract {
  ...
    public void suspendThisAndRelatedContracts () {
        if (alreadySuspended())
            return;
        makeSuspended();
        Collection contracts = findRelatedContracts();
        suspendGivenConracts(contracts);
        executeSuspensionWorkflow();
    }
  ...
    private void suspendGivenConracts(Collection contracts) {
        for (Contract c : contracts)
            c.suspendThisAndRelatedContracts();
    }
  ...
}

Nawet bez znajomości dziedziny można dokładnie powiedzieć co się dzieje. Co więcej taki kod można dość łatwo wytłumaczyć i przedyskutować jego poprawność w sensie funkcjonalności z ekspertem/klientem.