Jakiego modelu potrzebujemy?

Tworząc model domeny co konkretnie modelujemy? Czy chcemy mieć jeden model dla całego przedsięwzięcia czy wiele modeli? Czy można nie mieć modelu? Warto odpowiedzieć sobie na te pytania przed przystąpieniem do modelowania, żeby wiedzieć do jakiego celu zmierzamy.

W poprzednich artykułach określiliśmy model domenowy jako odwzorowanie tych aspektów rzeczywistości, które są istotne z perspektywy projektowanego systemu. Czym jest jednak ta rzeczywistość? Czy jest to świat fizycznych / wirtualnych przedmiotów i ich cech? Tak pojęte modelowanie sprowadzałoby się do zbierania rzeczowników i przekładania ich na tabelki bazodanowe. To może sprawdzać się w systemach, które jedynie zbierają dane. Problem w tym, że w ogromnej większości przypadków pracujemy przy o wiele bardziej skomplikowanych systemach.

Czym jest modelowana rzeczywistość?

Oprogramowanie biznesowe ma wspierać działalność operacyjną firmy. W tym działaniu najistotniejsze są procesy, zachowania i reguły nimi rządzące. Dane oczywiście są ważne, ale tylko o tyle, o ile umożliwiają realizację procesów i zachowań, czy sprawdzanie reguł.

Użytkownicy i inne osoby zainteresowane istnieniem systemu skupiają się na czynnościach, które wykonują na co dzień przy jego wsparciu. Przez pryzmat tych czynności patrzą oni na fizyczne / wirtualne przedmioty, które biorą w nich udział. Zobaczmy to na przykładzie domeny handlowej i przedmiotu jakim jest produkt. Klienta interesuje ile będzie on kosztował, gdy doda go do zamówienia. Magazyniera interesuje jak obsłużyć dostawy, jak przechować go na dostępnej powierzchni i jak dostarczyć go do klienta. Managera interesuje jak osiągnąć zaplanowane cele sprzedażowe. Serwisanta natomiast to jak obsłużyć proces zwrotów gwarancyjnych. Ten sam fizyczny przedmiot a cztery zupełnie różne perspektywy patrzenia.

Nasz model ma odzwierciedlać właśnie te perspektywy patrzenia a nie bezpośrednio fizyczne / wirtualne przedmioty. Modelujemy abstrakcje, które mają w głowach osoby zainteresowane istnieniem systemu, a nie same przedmioty. To te abstrakcje są czymś, na czym naprawdę nam zależy, co powinno zostać dobrze zrozumiane i wiernie oddane w modelu domenowym.

Ilu modeli potrzebujemy?

Skoro modelując skupiamy się na wielu różnych perspektywach patrzenia na to samo przedsięwzięcie, to jeden model obejmujący wszystko raczej nie będzie dobrym rozwiązaniem. Próba zrobienia takiego modelu napotyka kilka istotnych przeszkód np:

• Te same terminy będą używane w różnych znaczeniach przez różnych ludzi posiadających wiedzę domenową.
• Wiele miejsc w modelu będzie wypadkową wymagań mających różne powody do zmiany.
• Na granicach kompetencji poszczególnych ekspertów domenowych model będzie w większości przypadków nieprecyzyjny.
• Podział systemu na autonomiczne moduły utrzymywane przez osobne zespoły będzie bardzo trudny.

Katalog problemów można by oczywiście rozszerzać i uszczegóławiać dalej. Wszystkie one wynikają z jednej wspólnej przyczyny - wieloznaczności terminów wynikającej z istnienia różnych perspektyw patrzenia, czyli różnych abstrakcji w głowach ludzi zainteresowanych istnieniem systemu.

Dlatego warto mieć kilka różnych modeli produktu, posiadających różne zachowania i rządzących się różnymi regułami. Czy nie brzmi to jak koncepcja Bounded Contextów z Domain Driven Design? Tak dokładnie jest! Istnienie różnych perspektywach patrzenia na to samo przedsięwzięcie, jest powodem, dla którego podział na Bounded Contexty się sprawdza. Nie jest to tylko zabieg mający ograniczyć złożoność, z którą nie jesteśmy sobie w stanie poradzić. Jest to technika bazująca na tym jak faktycznie funkcjonuje działalność operacyjna firmy. To, że wszyscy w firmie mówią o produkcie nie znaczy, że musi to być jeden obiekt w systemie.

Total unification of the domain model for a large system will not be feasible or cost-effective.

​ - Eric Evans

Czy można nie mieć modelu?

A czy można w ogóle nie mieć modelu? Niestety nie! Nasz kod zawsze odzwierciedla pewien zestaw koncepcji będących (nie)zrozumieniem domeny przez zespół.

Złe modele powstają przez przypadkowe nawarstwianie się kolejnych abstrakcji, które podporządkowane są technicznej możliwości zamknięcia bieżących zadań, a nie zgodności z głęboko zrozumianą domeną.

Model taki jest często znany jedynie fragmentarycznie i nieprecyzyjnie przez członków zespołu, gdyż nikt nie projektuje go w sposób celowy. To jest właśnie prawdziwy dług techniczny, czyli przepaść jaka oddziela model od działalności operacyjnej. To dlatego dodanie przysłowiowego "checkboxa" zajmuje jedynie 3 miesiące.

Warto więc zainwestować w dobry model domenowy, bo nie da się nie mieć modelu, a zły jest praktycznie zawsze główną przyczyną problemów z utrzymaniem i rozwojem systemu.

Pozostałe artykuły w tej serii

Artykuły w tej serii będą analizą różnych wzorców i technik przez pryzmat tego, co z rzeczywistości biznesowej one modelują. Patrzenie na narzędzia, które stosujemy na co dzień, w ten sposób, może ułatwić zrozumienie, dlaczego pewne techniki mają sens i w jakich granicach mają one sens.

1. Programowanie jako modelowanie
2. Czym jest model?
3. Jakiego modelu potrzebujemy
4. Czy logika aplikacyjna to część modelu domeny?
5. Co modelują transakcje?
6. Co agreguje Agregat?
7. Czy Saga to transakcja rozproszona?
8. Kim jest modelarz?