Nadal obserwuję to, że model relacyjny i „tworzenie bazowych modeli danych na etapie analizy wymagań” (kanoniczny model danych) trzymają się twardo mimo tego, że nie wiele wnoszą do projektu a narzucają (sugerują) kiepską architekturę aplikacji z jedną relacyjna bazą danych.  Co ciekawe zaczynanie od bazy danych jest wręcz zaprzeczeniem zwinności (konieczność ukończenia projektu docelowej bazy danych przed rozpoczęciem kodowania czyli klasyka waterfall, w efekcie betonowanie stanu z dnia rozpoczęcia) mimo, że autorki artykułu piszą o sobie że są agile…)

Popatrzmy na to co proponują w tym 2017 roku.:

Jeśli w systemie istnieją określone reguły biznesowe, które określają maksymalne wartości relacji 0..n lub 1..n, można je uwzględnić w granicach kontekstu. Na przykład, PO dla SeiSounds może chcieć określić, że każde konto może być powiązane tylko z maksymalnie pięcioma użytkownikami lub słuchaczami, aby uniknąć sytuacji, w której znajomi kupują jedną płatną subskrypcję i dzielą się nią ze wszystkimi innymi. Proszę zobaczyć poniższy przykład:

[…]PODSUMOWANIE Diagramy danych biznesowych są jednym z tych modeli, które MUSZĄ BYĆ dla każdego produktu, który ma do czynienia z danymi. Samo ćwiczenie tworzenia modelu tworzy potężne, wspólne zrozumienie podstawowych konstrukcji danych, tak jak rozumieją je użytkownicy. BDD może również pomóc w zidentyfikowaniu dodatkowych, bardziej szczegółowych modeli, które mogą być potrzebne, a także w uzyskaniu pełnego zestawu historii użytkowników dotyczących interakcji użytkowników z danymi po wykonaniu czynności tworzenia, używania, edytowania, usuwania, przenoszenia i kopiowania. (Źródło: Deep Dive Models in Agile Series: Business Data Diagram) 

Powyższy model:

1. deklaruje konkretną znaną „na teraz”, wartość limitu liczby użytkowników Konta,
2. pomiędzy autorem, utworem i stacją  jest nic niemówiąca (każde z każdym bez żadnych ograniczeń) zależność,
3. pozostałe elementy nie wnoszą wartości dodanej (utwór jest cechą artysty czy może artysta jest cechą utworu…).

Zaryzykuję tezę, że powyższe w zasadzie nie pomaga developerowi w niczym. Czy wnosi coś do projektu? W moich oczach stanowi proste „zapisanie” tego co zeznali indagowani zamawiający (artykuł zawiera opis historyjek użytkownika i ich kojarzenia z tym modelem danych). Stwierdzenie zaś, że „…określone reguły biznesowe w systemie, które ustalają maksymalne wartości dla relacji 0..n lub 1..n…”, (np. maksimum pięcioro użytkowników może jednocześnie słuchać), to nie reguła biznesowa a kryterium decyzyjne (więcej o regułach biznesowych w literaturze). 

Trzeba sobie tu jasno powiedzieć, że indukcyjne podejście do analizy (zbieranie i zapisywanie obserwacji w celu identyfikacji trendu lub powtórzeń) przypomina próby zrozumienia gry w szachy metodą wielokrotnej obserwacji rozgrywek. Im wierniejszy opis gry ma powstać, tym więcej obserwacji należy udokumentować, co nie zmienia faktu, że taki dokument nie mówi absolutnie nic o przyszłych rozgrywkach. Alternatywą jest dedukcyjne podejście, polegające na zrozumieniu i opracowaniu, możliwie najmniejszym nakładem pracy, reguł gry w szachy, czego udokumentowanie wymaga najwyżej dwóch stron papieru A4, taki dokument opisuje także w 100% wszystkie przyszłe rozgrywki… 

Jak inaczej podejść do tego? 

Na początek należy zrozumieć dziedzinę problemu i opisać ją słownikiem:

Powyższy model pojęciowy (diagram notacji SBVR, diagram klas notacji UML) to słownik pojęć a nie model danych. To diagram obrazujący pojęcia i kontekstowe związki między nimi (tym kontekstem są fakty z dziedziny analizowanego problemu). Nie są to ani dane ani reguły biznesowe. Są to nazwy, a nie „byty systemowe”. Poza takim diagramem, należy także stworzyć słownik pojęć biznesowych w postaci tabeli zawierającej precyzyjne, dziedzinowe definicje tych pojęć. Dla wygody i prezentacji ich treści naniosłem dwie reguły na diagram, są skojarzone z Kontem gdyż jego dotyczą. Co do zasady reguły biznesowe są kojarzone z elementami na innych diagramach poprzez słowa zdefiniowane.

Cała analiza powinna się zaczynać od udokumentowania modeli procesów. Tu pominąłem te modele bo ich opisów jest na moim blogu wiele, a chcę się skupić na dziedzinie dla jakiej powstaje aplikacja. Analiza i zrozumienie problemu prowadzi do stworzenia modelu dziedziny aplikacji. Taki model powstaje na podstawie treści dokumentów wewnętrznych i zewnętrznych (tu np. Ustawa o prawach autorskich), pomagają co najwyżej bieżące wyjaśnienia.  Do jego powstania nie są potrzebne żadne warsztaty ani całodzienne spotkania.

Celem modelowania dziedziny systemu (tu aplikacji) jest udokumentowanie wewnętrznej logiki aplikacji, czyli mechanizmu jej działania. Absolutnie nie jest to model danych. Powyższy model nie jest modelem „ukończonym”, wymaga na pewno dopracowania, jednak moim celem jest jedynie pokazanie idei jego tworzenia. Nazwy klas, atrybutów, operacji zawierają pojęcia zawarte w słowniku pojęć. Zapewnia to jednoznaczność i zrozumienie. Dodam, że dopiero ten model pokazuje bardzo ważną rzecz, to że autor jest cechą utworu a nie odwrotnie. 

Tak więc:

1. uruchomienie i korzystanie z emisji kontrolowane jest przez Zarządzanie emisją, tu sprawdzane są i egzekwowane, reguły biznesowe, 
2. komponent Zarządzanie emisją korzysta także z informacji zawartych w Koncie użytkownika i Playlisty, detale utworów pobiera z Repozytorium utworów. 

Tu ważne jest podkreślenie, że reguła dotycząca ograniczenia liczby jednocześnie słuchających, jest oddzielona od Kont użytkowników i (nie pokazanych tu) Subskrypcji. Dzięki temu parametr ten jest łatwo modyfikowalny z poziomu aplikacji (parametryzowane kryterium decyzyjne) bez potrzeby jakichkolwiek ingerencji w „model danych”. Umieszczanie jakichkolwiek reguł w bazie danych (czyli na poziomie implementacji utrwalania) jest niestety ich „betonowaniem”.

Zmienność, nie tylko rynku ale i samych reguł w organizacjach, to stały element środowiska aplikacji. Dlatego dobrą praktyką jest, by utrwalanie danych (wszelkie bazy danych, pliki itp..) nie służyło do niczego poza utrwalaniem. Logika biznesowa powinna być w w 100% w aplikacji a nie podzielona pomiędzy aplikację i dane (żadna baza danych nie jest w stanie przechowywać innych reguł biznesowych niż bezpośrednie związki ilościowe). Na etapie implementacji, stosujemy zasadę hermetyzacji, czyli nie współdzielimy, na żadnym poziomie, danych pomiędzy repozytoriami i nie usuwamy redundancji. Dzięki temu nie odcinamy sobie drogi do zmian systemu takich jak np. zastąpienie klasy Dane osobowe interfejsem do zewnętrznego systemu, dysponującego takimi informacjami (klasa ta zostanie zmieniona, stanie się wtedy mostem do API zewnętrznego systemu co nie pociągnie za sobą jakichkolwiek zmian, bo interfejs tej klasy i jej nazwa pozostaną niezmienione, patrz zasada open-close principia oraz polimorfizm).

Poniżej kluczowe związki w UML i ilustracja związku pomiędzy modelem pojęciowym a modelem struktury (architektury, to model dziedziny):

Na zakończenie warto zauważyć, że zmienność środowiska biznesowego powoduje, że żadne decyzje o logice biznesowej nie są ostateczne, jednak są elementy niezmienne takie jak np. nasze dane osobowe. Tak więc to, co powszechnie nazywane jest „modelem danych” (business data diagram) w rozumieniu opisanym przez autorki artykułu, nie ma dzisiaj racji bytu. Ma sens zachowanie zamówienia i osobno faktury, ale to czy regułą jest jedno zamówienie do jednej faktury, podlega zmianom wynikającym i ze zmienności prawa i ze zmienności modeli biznesowych. Nie widzę żadnego powodu deklarowania już na początku projektu, tego by nie więcej niż 5 osób mogło korzystać z jednego konta i subskrypcji. W szczególności nie widzę powodu by taka zasada była zawarta w samym kodzie aplikacji.

Warto także mieć na uwadze to, że oprogramowanie może być tworzone z użyciem zewnętrznych komponentów dostępnych na rynku.  Założenie więc na samym początku projektu, że dane są w jednolity sposób przechowywane i współdzielone w jednej centralnej i współdzielonej bazie danych, wraz z logiką ich użycia, jest tu nie tylko nieuzasadnione ale wręcz szkodliwe. 

I na koniec gratka: dokładnie ta powstała, i nadal tak wygląda, znaczna większość obecnych na rynku systemów ERP, CRM itp…. 

oraz cytat z literatury

z 1994 roku: