Logika aplikacji, a logika biznesowa

Ten post jest pierwszym z cyklu poświęconego architekturze systemów informatycznych. Zaczynamy od wyjaśnienia pojęć logiki biznesowej i logiki aplikacji na przykładzie małej aplikacji ASP.NET MVC. Więcej na temat MVC w kolejnym artykule. Już teraz zapraszam.

Uczestnicząc w dyskusjach zarówno w życiu zawodowym jak i wirtualnym spotykam się z myleniem wymienionych w tytule artykułu pojęć, bądź używaniem ich zamiennie. Chociaż na pierwszy rzut oka mogło by się wydawać, że logika biznesowa jest tym samym co logika aplikacji, no bo w końcu aplikacja realizuje pewne założenia biznesowe, jest jednak zupełnie inaczej. No więc jak to jest?

Na początek rozważmy poniższy fragment kodu:

Widzimy klasę Order, która jest naszym obiektem biznesowym (Business Object). W Domain Driven Design nazwalibyśmy go obiektem domeny (Domain Object). W tym artykule nie będę skupiał się na DDD, więc dalej będę posługiwał się nazwą „obiekt biznesowy”. Jak możemy zauważyć wszystkie właściwości mają prywatne settery. Dzięki temu nasz obiekt biznesowy pozostaje nizemienny i spójny (immutable). Aby zmienić którąś z właściwości, musimy napisać specjalną metodę, która tę operację wykona. Dzięki temu programista korzystający z powyższego obiektu, nie będzie w stanie zmodyfikować jego właściwości, jeżeli mu na to nie pozwolimy.

Obiekt posiada 3 publiczne metody. Pierwsze dodaje wybrany order item do zamówienia, druga usuwa order item z zamówienia, a trzecia wylicza całkowitą wartość zamowienia. Jak widzimy metody te są ściśle związane z procesem biznesowym. W tym przykładzie procesem biznesowym jest złożenie zamówienia. Nie sprawdzamy w tym miejscu czy dane są poprawne, nie walidujemy formularza itd. Nie od tego jest logika biznesowa. Logika biznesowa to implementacja pewnego procesu biznesowego. Jedyną walidację jaką w warstwie logiki biznesowej powinniśmy przeprowadzać to walidacja samego procesu biznesowego i operacji ściśle z nim związanych. Na tym etapie skupiamy się tylko i wyłącznie na procesie biznesowym.

Gdzie zatem przeprowadzamy walidację danych wejściowych? Otóż jak można się już domyślić, taką walidację możemy przeprowadzić w logice aplikacji.

Logika aplikacji to warstwa pomiędzy warstwą logiki biznesowej, a warstwą prezentacji. Do jej obowiązków należy kontrolowanie przepływu (flow) programu, może również przeprowadzać walidację danych wejściowych, przed przekazaniem ich do warstwy logiki biznesowej. Przez słowo „również” mam na myśli to, że walidację formularza możemy przeprowadzić także w warstwie logiki prezentacji (korzystając możliwości jakie daje nam technologia AJAX, czy atrybuty w ASP.NET MVC). Mówiąc „przepływ” mam na myśli koordynację zadań pomiędzy warstwą prezentacji, warstwą logiki biznesowej oraz warstwą infrastruktury.

Spójrzmy na poniższą metodę post kontrolera ASP.NET MVC:

Zaczynamy od walidacji danych użytkownika przy użyciu obiektu LogOnService. Następnie jeżeli dane logowania są poprawne generujemy FormsAuthenticationTicket za którego pomocą tworzymy ciasteczko (cookie) i w zależności od roli w jakiej znajduje się użytkownik przekierowujemy do właściwego widoku. Widzimy więc, że powyższa metoda dokonuje walidacji danych oraz steruje logiką aplikacji. Podobnie będzie wyglądał kontroler składania zamówienia. Przed przekazaniem danych do właściwego obiektu biznesowego (Order) dokonamy sprawdzenia poprawności danych i w zależności od wyniku dodamy nowe zamówienie, albo poinformujemy użytkownika, że formularz zamówienia posiada błędy, które muszą zostać usunięte, aby kontynuować proces zamawiania. 

Warto również zastanowić się czy jest sens trzymać logikę aplikacji w kontrolerach. Odpowiedź - to zależy. Dla małych aplikacji takie rozwiązanie będzie ok. Co to jest mała aplikacja? To taka aplikacja, której logika nie jest skomplikowana, czyli dokonujemy prostych walidacji danych, coś tam policzymy, zapiszemy/odczytamy ze źródła danych.

W dużych systemach, gdzie logika jest złożona stosuje się inne rozwiązania, ale to temat na osobny artykuł, może nawet dwa lub trzy. W tym miejscu tylko dodam, że w takich aplikacjach kontroler pełni rolę "pośrednika", który odbiera żądanie od warstwy prezentacji i przekazuje je dalej, w głąb aplikacji nie robiąc po drodze nic. Tak samo w drugą stronę.

Podsumujmy.

Logika biznesowa jest to implementacja procesów biznesowych (tworzenie zamówień, generowanie raportów). Odpowiedzialność za realizację procesów biznesowych ponoszą odpowiednie obiekty biznesowe. Należy zauważyć, że obiekty biznesowe nie są anemiczne – oprócz atrybutów posiadają „stan” i „odpowiedzialność”. Obiekty te są niezmienne i spójne.

Logika aplikacji może być implementacją przypadków użycia (złóż zamówienie, wygeneruj raport). Koordynuje zadania pomiędzy warstwami. Często stanowi fasadę (wzorzec projektowy Facade) opakowując funkcje aplikacji, chowając je za interfejsami, które mogą pełnić rolę API. Dzięki takiej enkapsulacji, możemy tworzyć różne wersje aplikacji (internetowa, desktop, mobilna) lub nawet udostępnić funkcje naszej aplikacji innym aplikacjom poprzez stworzenie web service’u, lub dedykowanych adapterów (wzorzec projektowy Adapter).