Niedawno napi­sa­łem:

opro­gra­mo­wa­nie repre­zen­tu­je narzę­dzie pra­cy, więc pro­jekt tego opro­gra­mo­wa­nia raczej powi­nien zawie­rać poję­cie (kla­sę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podo­ba mi się kla­sa Pracownik?).

To sta­ły temat wie­lu dys­ku­sji z pro­gra­mi­sta­mi. Ostatnio, po pew­nym szko­le­niu, w ramach wspar­cia po szko­le­niu jakie zawsze świad­czę, zno­wu padło pytanie:

Czy zda­rza Ci się robić analizy/projekty, gdzie byty wystę­pu­ją pod nazwa­mi inny­mi niż uży­wa­ny­mi potocz­nie przez Biznes.

Z tym – uży­wa­ne poję­cia – jest regu­lar­nie duży pro­blem, dla­te­go od pew­ne­go cza­su orto­dok­syj­nie sto­su­ję budo­wa­nie ​„prze­strze­ni poję­cio­wej” dla pro­jek­tu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słow­nik pojęć, listę reguł biz­ne­so­wych (to nie to samo co regu­ły decy­zyj­ne) oraz tak zwa­ny dia­gram fak­tów, któ­ry słu­ży do testo­wa­nia (i doku­men­to­wa­nia słow­ni­ka) – upew­nie­nia się, że poję­cia nie koli­du­ją ze sobą a ich defi­ni­cje nie nakła­da­ją się na sie­bie oraz, że lista jest dzie­dzi­no­wo kom­plet­na. Po co to? Właśnie po to,

by żad­ne zde­fi­nio­wa­ne sło­wo nie mia­ło w pro­jek­cie (w wyma­ga­niach, w kodzie) wię­cej niż jed­ne­go zna­cze­nia i by zna­cze­nie każ­de­go zefi­nio­wa­ne­go poję­cia nie budzi­ło żad­nych wątpliwości

(co nie­co o słow­ni­kach ter­mi­nów: Reguły biz­ne­so­we jako motor ste­ru­ją­cy orga­ni­za­cji: fak­ty + defi­ni­cje pojęć).

Jedna uwa­ga na począ­tek: jeże­li ​„byty” (kla­sy) w kodzie (pro­jek­cie) opro­gra­mo­wa­nia wystę­pu­ją pod inny­mi nazwa­mi niż w rze­czy­wi­sto­ści, to jest to abso­lut­na poraż­ka, bo pro­gra­mi­sta zupeł­nie tra­ci kon­takt z klien­tem i (lub) doku­men­ta­cją opi­su­ją­ca wyma­ga­nia. Jeżeli już koniecz­nie pro­gra­mi­sta musi ulżyć sobie w ambi­cji uży­wa­nia wyłącz­nie j.angielskiego w kodzie, powi­nien ten kod być boga­to komen­to­wa­ny, by nie było wąt­pli­wo­ści jakie znacz­nie nie­sie np. nazwa kla­sy czy atry­bu­tu (tym bar­dziej, że np. sło­wo name to nie tyl­ko nazwisko.….)

Słownik pojęć (czę­sto wystę­pu­je w doku­men­tach jako czy­sto pol­skie sło­wo glos­sa­riusz ;)) bywa czę­sto przed­mio­tem burz­li­wych nego­cja­cji, bo nie raz (a w zasa­dzie zawsze ;)) biz­nes sto­su­je slang, w któ­rym to samo sło­wo ma róż­ne zna­cze­nie, zależ­nie od kon­tek­stu uży­cia. Może to mieć sens w języ­ku mówio­nym gdy peł­na treść wypo­wie­dzi daje ten kon­tekst, ale na pozio­mie ana­li­zy i pro­jek­tu każ­de poję­cie musi mieć jed­no uni­kal­ne znacz­nie mimo bra­ku kon­tek­stu (tym bar­dziej, że np. nazwy klas nie są ele­men­ta­mi peł­nych zdań ani opowieści :)).

Pamiętam pro­jekt, w któ­rym wice­pre­zes pew­nej fir­my na każ­de dzia­ła­nie takie jak nowa umo­wa, nowy pro­jekt, nowy klient, uży­wał sło­wa ​„temat”, nikt nie miał odwa­gi powie­dzieć mu, że nie raz nie rozu­mie o czym on mówi … Ja – obcy – się odwa­ży­łem 🙂 i upo­rząd­ko­wa­li­śmy to, był opór ;). Pamiętam, że dyplo­ma­tycz­nie popro­si­łem go by zbu­do­wał hie­rar­chię ​„tema­tów” nazy­wa­jąc każ­dy ele­ment tej hie­rar­chii jed­nym lub dwo­ma sło­wa­mi sło­wa­mi i pomo­gło :), Słownik pojęć to negocjacje 🙂

Evans (DDD ) zapo­cząt­ko­wał bar­dzo cie­ka­we podej­ście, ono się roz­wi­ja. Co cie­ka­we Evans nie wymy­ślił idei a sys­tem wzor­ców DDD. Wspólny język to dwa ele­men­ty: uży­wa­nie biz­ne­so­wych nazw (bez skró­tów) na ele­men­ty rze­czy­wi­ste i kla­sy w sys­te­mie, ale tak­że uży­wa­nie np. poję­cia ​„fabry­ka” przez biz­nes i przez deve­lo­pe­ra jako ​„kon­te­ner” na pewien rodzaj kom­pe­ten­cji (wie­dza o tym jak powsta­ją pew­ne obiek­ty biznesowe).

Elementy wzor­ca DDD to nie tyl­ko blo­ki kodu, to tak­że ele­men­ty (kla­sy­fi­ka­to­ry) wie­dzy o biz­ne­sie. Faktura VAT to agre­gat – struk­tu­ra infor­ma­cji, to tyl­ko wie­dza o tym co ten doku­ment zawie­ra, ale FabrykaFaktur to odręb­na wie­dza o tym jak ten doku­ment jest two­rzo­ny. Należy świa­do­mie udo­ku­men­to­wać oba byty: doku­ment i recep­ta jego two­rze­nia. Dlaczego osob­no? Bo po pierw­sze wysta­wio­ne fak­tu­ry żyją wła­snym, życiem i obcią­ża­nie każ­dej z nich (np. tysiąc fak­tur mie­sięcz­nie) całą wie­dza jak powsta­ła nie ma więk­sze­go sen­su. Po dru­gie zmia­na prze­pi­sów nie powin­na się odbić na doku­men­tach już wysta­wio­nych ani docią­żyć nowo powstających.

Biznes tak­że musi zro­zu­mieć, że ma dwa róż­ne ele­men­ty opi­su swo­ich dzia­łań: pra­ca z doku­men­ta­mi i two­rze­nie doku­men­tów. Jednak uzna­nie tego fak­tu to jed­no, nie wie­rzę w to, że biz­nes się tego nauczy, bo nie nauczył się for­mal­ne­go opi­su lub mode­lo­wa­nia pro­ce­sów pod­czas wdro­żeń ISO, jed­nak uwa­żam, że biz­nes nie ma takiej potrze­by. Moim zda­niem od dobre­go ana­li­ty­ka nie ma uciecz­ki, to inna kom­pe­ten­cja. Nie ma uciecz­ki od pro­jek­tan­tów mody mimo ist­nie­nia kobiet chcą­cych mieć ład­ne sukien­ki i bar­dzo dobrych kraw­ców. Nikt tu niko­go nie zastąpi.

Czy Model dziedziny ma stan?

(to część bar­dziej techniczna)

W kwe­stii cze­goś takie­go jak Stan Modelu w MVC (czy model biz­ne­so­wy ma stan?) jestem ostroż­ny z uży­wa­niem poję­cia ​„stan”, popa­trz­my na gry kom­pu­te­ro­we… Czym jest stan? Stan na pewien moment w cza­sie (snap­shot) czy stan ​„biz­ne­so­wy” trwa­ją­cy minu­ty, godzi­ny a nie raz dłu­żej? Model to sys­tem: zespół ele­men­tów współ­dzia­ła­ją­cych. Z per­spek­ty­wy biz­ne­su, reagu­je on na akcje (sta­bil­ny ekran ocze­ki­wa­nia na OK, to per­ma­nent­ny maszy­no­wy prze­bieg spraw­dza­nia sta­nu przy­ci­sków). Osobiście trak­tu­ję kla­sy Modelu jako samo­dziel­ne żyją­ce byty, kon­struk­cja metod musi zagwa­ran­to­wać brak błę­dów i radzić sobie z tym co ​„sta­łe” dla użyt­kow­ni­ka i ​„zmien­ne” dla sys­te­mu (zegar bez sekund­ni­ka jest z per­spek­ty­wy minut mar­twym przed­mio­tem a mimo to ​„cho­dzi”).

Podejście do MVC, któ­re prak­ty­ku­ję: Model powi­nien reali­zo­wać 100% funk­cjo­nal­no­ści i dać się testo­wać bez war­stwy V i C. Konkretnym sta­nem raczej cha­rak­te­ry­zu­je się kon­kret­ny obiekt a nie cały sys­tem. Cały sys­tem moż­na zapew­ne opi­sać maszy­ną sta­no­wą ale po co, sko­ro są ich nie­zli­czo­ne ilo­ści? Model żyje jak mro­wi­sko, wystar­czy zro­zu­mieć mrów­ki, mro­wi­sko to sku­tek na któ­ry za bar­dzo nie mamy wpływu.

Model DDD ​„ana­li­tycz­ny” to meta­mo­del imple­men­ta­cji, Evans trak­tu­je go jako ​„blo­ki kodu” zro­zu­mia­łe przez biz­nes, idąc dalej: ana­li­tyk trak­tu­je DDD jako wie­dzę o biz­ne­sie w posta­ci zro­zu­mia­łej przez deve­lo­pe­ra. Obie stro­ny uzna­ją, że ta struk­tu­ra jest wza­jem­ną ​„umo­wą”. Jestem zwo­len­ni­kiem takie­go podej­ścia do DDD :), Evans się z tym w moich oczach nie kło­ci, on w zasa­dzie nie pisał o ana­li­zie biz­ne­so­wej :). Wielu pro­gra­mi­stów, auto­rów dosko­na­łych ksią­żek, zakła­da, że ​„ana­li­zę wyma­gań ma popraw­nie wyko­na­ną”, co by to nie mia­ło zna­czyć :), ale to ogrom­ne uprosz­cze­nie bo tu – błę­dy – tkwi więk­szość ryzyk projektu.

Więcej o słow­ni­kach i regu­łach biznesowych:

(OMG, Glossary, Business Rules, http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​S​e​m​a​n​t​i​c​s​_​o​f​_​B​u​s​i​n​e​s​s​_​V​o​c​a​b​u​l​a​r​y​_​a​n​d​_​B​u​s​i​n​e​s​s​_​R​u​les oraz http://​en​.wiki​pe​dia​.org/​w​i​k​i​/​B​u​s​i​n​e​s​s​_​r​ule, http://​www​.visu​al​-para​digm​.com/​s​u​p​p​o​r​t​/​d​o​c​u​m​e​n​t​s​/​b​p​v​a​u​s​e​r​g​u​i​d​e​/​2​0​1​7​/​2​1​8​1​/​5​7​0​4​3​_​c​r​e​a​t​i​n​g​f​a​c​t​.​h​tml).