Czym jest model?

W pracy nad każdym systemem IT opracowujemy "MODEL". Czym on jednak jest? Czy wszystkie modele są błędne? Czasami warto oderwać się nieco od technikaliów i spojrzeć na tworzenie systemów IT z nieco "filozoficznej" perspektywy.

Koncepcja tworzenia modeli nie ogranicza się jedynie do IT. De facto cały czas otaczamy się różnego rodzaju modelami od map topograficznych do teorii fizycznych. Model jest odwzorowaniem rzeczywistości, w którym staramy się uwypuklić jakiś jej aspekt pomijając pozostałe. Jest więc zawsze pewnym uproszczeniem, ale w aspekcie, który ma zostać wyeksponowany powinien wiernie odzwierciedlać modelowaną rzeczywistość.

W IT koncepcja ta też jest obecna i to już od dość długiego czasu:

[...] every model represents some aspect of reality or an idea that is of interest. A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.

​ - Eric Evans

Czy model to diagram, kod, a może coś jeszcze innego?

Czy model jest po prostu kodem, który realizuje funkcjonalności? A może jest to diagram, bo przecież szczegóły konkretnego języka nie mają nic wspólnego z biznesem? A czy notacja UML (lub jakakolwiek inna) ma? A może to pytanie jest po prostu źle postawione?

Model to zestaw koncepcji odzwierciedlających te aspekty działania przedsiębiorstwa, które mają być wspierane przez projektowany system IT. Należą do nich procesy, zachowania, reguły, algorytmy (np. wyceny), dane, etc. Nie jest to jednak nieuporządkowany zbiór luźno powiązanych koncepcji. Jest to wiedza na tyle precyzyjna i uporządkowana, że może być przełożona na działający kod (a jak wiemy kompilator nie wybacza nieścisłości).

Podobnie jest w fizyce. Model rzeczywistości to poznane prawa rządzące wybranym aspektem fizycznego świata np. grawitacją. Można je zapisać w postaci wzorów, ale sam model to poznawcze ujęcie jak pewne procesy zachodzą w rzeczywistości. Same wzory to zresztą często za mało, żeby oddać całość modelu.

Model w IT (podobnie jak w fizyce) jest ze swej natury niematerialny, gdyż należy do sfery naszego poznania. Kod, diagram, karteczki na sesji Event Sormingu, etc. to jego materialne reprezentacje. Służą nam do komunikowania się ze sobą, ale nie są w stanie zastąpić zrozumienia w głowach członków zespołu deweloperskiego, które jest konieczne, żeby system robił to, czego oczekuje biznes.

A domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert's head; it is a rigorously organized and selective abstraction of that knowledge.

​ - Eric Evans

Reprezentacja modelu jaką jest kod oczywiście ma tu uprzywilejowane miejsce, gdyż jest on jednocześnie definicją systemu, o którego powstanie nam chodzi.

Czy model jest prawdziwy?

Na konferencjach, podcastach i blogach często można spotkać się ze stwierdzeniem, że "wszystkie modele są błędne, ale niektóre są użyteczne". Stwierdzenie to pochodzi od statystyka George'a Boxa. Było ono powtórzone już tak wiele razy, że wydaje się oczywiste. Czy jest ono jednak prawdziwe w kontekście systemów IT?

Jeżeli model jest odzwierciedleniem rzeczywistości, to jest prawdziwy, gdy przedstawia cechy tej rzeczywistości w taki sposób, w jaki one w niej istnieją. Przykładowo mapa, która ma wiernie zachowywać odległości jest prawdziwa, gdy odległości na niej są takie, jak w rzeczywistości pomniejszone o podany czynnik - skalę. Odległości te nie muszą być identyczne jak w rzeczywistości (mapa w skali 1:1 nie ma sensu). Nie muszą być też zachowane powierzchnie (nawet po przeskalowaniu), jeżeli dana mapa obiecuje jedynie zachowanie odległości, a powierzchni już nie.

Jeżeli model jest błędny, to znaczy, że tego nie robi, czyli odwzorowuje rzeczywistość nieadekwatnie. Czy chcemy mieć taki model? Raczej nie. Do czego służyła by mapa odwzorowująca odległości, która odwzorowuje je błędnie? W systemach IT nieadekwatne odwzorowanie to bug, a w najlepszym razie coś, co będzie utrudniało rozwój systemu w przyszłości.

Wiele modeli jest błędnych, niektóre są prawdziwe i z tych warto wybrać ten, który jest najbardziej użyteczny.

Sama użyteczność to o wiele za mało. Różne rzeczy są użyteczne np: hakowanie przed wdrożeniem, czy zaciąganie długu technicznego. Coś może też być użyteczne, ale chwilowo, przez przypadek. Pytanie jaka jest nasza perspektywa czasowa. Jeżeli do najbliższego wdrożenia, to co innego jest użyteczne, a jeżeli przez kolejną dekadę, to zupełnie co innego. A jaka jest perspektywa czasowa tych, którzy ostatecznie finansują powstanie systemu?

W długiej perspektywie czasowej użyteczne jest tylko to co prawdziwe.

To, że model jest prawdziwy, nie wymaga żeby odwzorowywał całą działalność operacyjną firmy we wszystkich jej aspektach. Model powstaje w procesie abstrakcji, ze swej istoty musi więc coś pomijać. Model, który pomija zbyt mało jest użyteczny tak samo jak mapa w skali 1:1.

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?