Życia nie oszukasz

Kolejność to podstawa.
Jako przykład weźmy tę oto prozaiczną sytuację:
Wchodzisz do toalety, podnosisz deskę, siadasz, defekujesz, spuszczasz wodę, ściągasz spodnie.

Chyba oczyma wyobraźni widzimy jak zgubne w skutkach może być pomieszanie kolejności faz w nawet tak prostym procesie. A co dopiero musi się dziać w procesach bardziej złożonych... np podczas wytwarzania oprogramowania?
"... mnie oszukasz, przyjaciela oszukasz, mamusię oszukasz ale życia nie oszukasz ... "


Rebecca Brock zajmująca się "przeglądem" systemów i architektur w swej prezentacji dziwi się jak często na pytanie o analizę biznesową czy projekt domenowy zostaje jej radośnie przedstawiona baza danych.
J. B. Rainsberger jest bardziej radykalny. W swym felietonie opisuje doświadczenia z projektu, w którym zdecydował się na projektowanie bazy na koniec procesu wytwórczego.

/*
 * O ile zbytnio nie zachęcam do oglądania
 * prezentacji Pani Brock,
 * to felieton Rainsbergera polecam.
 */


Hmm czyli to, co od jakiegoś czasu podpowiada intuicja nie jest objawem jakiegoś schorzenia - inni też na to wpadli:)
Bo do czego prowadzi przedwczesne projektowanie bazy? Jeszcze nic nie wiemy o przyszłym systemie, wymagania wciąż się zmieniają a my już inwestujemy ogromną ilość czasu (zasobów w ogólności) w projekt bazy. Zaraz po tym piszemy zapytania (SQL, HQL, Criteria API), które po zmianach schematu bazy są do wyrzucenia albo przynajmniej gruntownego przepisania. Oczywiście o wiele taniej jest zmieniać model klas niż model klas, i bazy, i zapytania.

Co gorsza - z czasem gdy baza osiągnie masę krytyczną nikt nie odważy się na podjęcie decyzji o zmianie schematu! Przecież zbyt wiele DAO byłoby do przepisania! Zatem mamy piękną paranoję pod tytułem "DB driven development" - naciąganie rzeczywistości do istniejącego schematu bazy - schematu, który powstał gdy prawie nic nie wiedzieliśmy o wymaganiach; schematu, z którym po prostu musimy nauczyć się żyć:)

Rainsberger podaje jakże prostą i oczywistą metodykę: use a "dummy" persistence mechanism. Czyli jak długo się da (najlepiej do release) odwlekamy stworzenie bazy. Posługujemy się Mockowatymi implementacjami DAO albo Repozytoriów. Czyli najpierw (np. iteracyjne) rozwijamy model domenowy. Z czasem, gdy model domenowy okrzepnie możemy wreszcie przygotować tabele, które go będą utrwalać.


//======================


Rainsberger opisał sukces projektu opartego na Domain Driven Design. Czyli podejścia gdzie jesteśmy na takim poziomie świadomości, że rozumiemy iż Model Domenowy jest "sercem" systemu. To tam zawarte są reguły biznesowe, które sprawiają najwięcej problemów z utrzymaniem i rozbudową. Model domenowy modeluje byty biznesowe i interakcje pomiędzy nimi; baza jest tylko strukturą danych utrwalającą jakąś część modelu.

Pustkę po dobrym modelu domenowym można wypełnić tylko jednym: spaghetti:)
Spaghetti to wężowisko procedur (zapakowanych w klasy i dumnie nazywanych metodami) oplatających istniejącą strukturę bazy danych. Procedur, które powielają swą logikę, mieszają odpowiedzialności i zazwyczaj charakteryzują się wieloma zależnościami. Z czasem nikt nad nimi nie panuje, nie próbuje nawet refaktoryzowac; po prostu dolepia się kolejne:)
Spaghetti może i działa w wersji 1.0 ale z czasem osiągnie masę krytyczną uniemożliwiającą zmiany w jednym miejscu bez zniszczenia miejsc innych.

Przedstawione przez Rainsbergera podejście oczywiście nie sprawdzi się, gdy musimy często pokazywać działające wersje klientowi, który nie zadowoli się tym, że na jednym ekranie coś dodał/edytował a na ekranie z listą nie widzi zmian. No ale jeżeli klient nie potrafi unieść się na lekko wyższy poziom abstrakcji to może nie warto z nim robić interesów - zapowiadają się same problemy;P

Schemat bazy jakże często jest mylony z analizą czy modelem domenowym. Na schemacie widzimy co najwyżej strukturę danych, brak tam obrazu odpowiedzialności (dynamiki) czyli modelu biznesu.

I jeszcze jeden szczegół: dlaczego przechowywać byty ze świata obiektowego w relacyjnej bazie danych zamiast w obiektowej? :P