If ifowi nie równy. Znamy tę prawdę już nie od dziś. Oczywiście można na tę relację spojrzeć z różnych perspektyw. My natomiast skupimy się teraz na perspektywie dotyczącej rodzajów logik. Spojrzymy na nią przez pryzmat otrzymywanych wymagań biznesowych.

“Nie możesz ściągnąć wybranego filmu więcej niż 5 razy”

Z taką czy też podobną regułą mogłeś/mogłaś się spotkać korzystając z serwisów VOD. Zastanówmy się jakiego rodzaju danych potrzebujemy, aby sprawdzić tę regułę. Na pewno stan z bazy danych będzie niezbędny, ponieważ musimy wiedzieć ile razy dany film został już pobrany przez użytkownika w przeszłości. W żądaniu do systemu niezbędna jest informacja o jakim filmie jest w ogóle mowa.

Mamy więc zderzenie dwóch światów. Tego zawartego w bazie danych i tego zewnętrznego. Dlatego w tym przypadku mówimy o regule spójności. Ograniczeniu, które nakładamy na oprogramowanie z racji obranego modelu biznesowego. Ten niezmiennik nigdy nie powinien zostać naruszony.

“Numer VIN pojazdu musi być prawidłowy”

Tak samo jak wyżej, jest to niezmiennik. Jednak w tym przypadku jest to walidacja lokalna. Nie ma potrzeby wyciągania stanu z bazy danych, aby dokonać weryfikacji wartości przekazanej jako numer VIN. No dobra, można regex trzymać w bazie danych, ale to nie jest stan biznesowy. Sama walidacja może być dokonana na GUI, a potem powtórzona na backend (w myśl pragmatycznego podejścia przedstawionego na prezentacji Łukasza Szydło). I nie ma w tym nic złego.

“Jeśli klient pobrał film po raz 4 to wyślij do niego email”

Często zdanie posiadające składnie “jeśli … to …” opisuje logikę procesową, zwaną inaczej logiką integracyjną. Tutaj nie bronimy niezmienników. Chcemy wykonać jakiś krok z powodu zmiany jaka zaszła w systemie. Ale nie w przypadku każdej zmiany, tylko konkretnej. W naszym przypadku, kiedy klient pobierze film po raz 4.

Mówimy wtedy o orkiestracji czy też koordynacji procesu biznesowego. Wykonujemy poszczególne kroki danej logiki biznesowej. Głównie będzie to komunikacja z wybranymi modułami naszej aplikacji albo zewnętrznymi systemami. Możemy komunikować się z serwisem A pod jakimiś warunkami albo z serwisem B w innym przypadku.

“Pojazdy są przypisywane do draftu polisy”

Pytań co do tego stwierdzenia, wymagania biznesowego, jest cała masa. Czy to faktycznie pojazd musi być świadomy do jakiego draftu polisy został przypisany? Czy jednak to draft polisy powinien wiedzieć jakie pojazdy są z nim powiązane? Czy może jednak to powiązanie nie ma nic wspólnego z logiką biznesową tylko powstało na potrzeby graficznego interfejsu użytkownika? Ciężko sprowadzić to wymaganie do jednego ifa. Wszystko zależy od masy różnych rzeczy. W tym kontekście nie mówimy o walidacji czy procesie. Skupiamy się na modelu jaki ma być dostosowany pod to konkretne wymaganie. Jeśli go dobrze stworzymy to kod stanie się przejrzysty i prosty w utrzymaniu.

Mam nadzieje, że ten wpis przedstawił Ci sposób w jaki możemy skategoryzować logikę biznesową. W ten sposób liczę, że jak zobaczysz jakiegoś ifa to będziesz miał w pamięci, że if ifowi nie równy…