W dobrze zaprojektowanej aplikacji to nie interfejs ani baza danych decydują o tym, co wolno zrobić użytkownikowi. Robi to warstwa odpowiedzialna za zasady działania systemu: walidacje, przepływy, obliczenia, limity i decyzje zależne od kontekstu. W tym artykule rozkładam na części logikę biznesową aplikacji, pokazuję, gdzie ją trzymać, jakie wzorce pomagają ją uporządkować i jak uniknąć typowych błędów.
Najważniejsze rzeczy, które warto wiedzieć o tej warstwie
- Logika biznesowa opisuje reguły i decyzje, a nie wygląd ekranu ani techniczne szczegóły zapisu danych.
- Najzdrowiej jest oddzielić ją od warstwy prezentacji i infrastruktury, bo wtedy zmiany są tańsze i mniej ryzykowne.
- W prostych aplikacjach wystarczy często cienka warstwa serwisów, ale przy złożonej domenie lepiej sprawdza się bogaty model domenowy.
- Wzorce takie jak Service Layer, Repository, Domain Model i podejście DDD pomagają utrzymać porządek.
- Najgorsze problemy biorą się zwykle z mieszania reguł biznesowych z kontrolerami, widokami i kodem dostępu do bazy.
- Jeśli reguły zaczynają rosnąć, warto je testować jednostkowo poza UI i poza ORM-em.
Gdzie naprawdę mieszka logika i czego nie powinno się do niej doklejać
Ja zwykle tłumaczę to bardzo prosto: interfejs pyta, logika decyduje, baza przechowuje. Jeśli aplikacja ma policzyć rabat, sprawdzić limit zamówienia, zmienić status sprawy albo odrzucić operację z powodu reguły domenowej, to właśnie tam pracuje jej rdzeń. Gdy te decyzje lądują w kontrolerach, widokach albo zapytaniach SQL, projekt szybko robi się trudny do zmiany.
W praktyce warto rozdzielić trzy obszary. Warstwa prezentacji obsługuje formularze, API i komunikaty dla użytkownika. Warstwa biznesowa wykonuje przypadki użycia i pilnuje reguł. Warstwa dostępu do danych odpowiada za zapis, odczyt i mapowanie encji. To rozdzielenie nie jest akademicką zabawką, tylko sposobem na to, żeby zmiana w jednym miejscu nie rozsypała całego systemu.
| Obszar | Za co odpowiada | Przykład | Czego tam nie trzymać |
|---|---|---|---|
| Prezentacja | Wejście i wyjście dla użytkownika | Walidacja pola wymagane, render formularza | Reguł typu „nie można anulować opłaconego zamówienia” |
| Logika biznesowa | Decyzje, reguły, przepływy, obliczenia | Wyliczenie rabatu, zmiana statusu, sprawdzenie dostępności | Szczegółów HTML, requestów HTTP i SQL |
| Dostęp do danych | Odczyt i zapis stanu | Repozytorium zamówień, zapis transakcji | Reguł, które mają znaczenie biznesowe |
Właśnie dlatego warto patrzeć na aplikację jak na układ współpracujących warstw, a nie na jeden wielki plik z logiką „gdzieś po drodze”. To prowadzi nas do wzorców, które pomagają ten układ utrzymać w ryzach.
Jakie wzorce najczęściej porządkują tę część systemu
W dobrze prowadzonych projektach nie chodzi o to, żeby użyć jak największej liczby wzorców. Chodzi o to, żeby wybrać takie, które pasują do złożoności domeny. Ja zwykle zaczynam od pytania: czy problem jest prosty i proceduralny, czy reguły są na tyle bogate, że zasługują na własny model?
| Wzorzec | Kiedy pasuje | Plusy | Ryzyko |
|---|---|---|---|
| Transaction Script | Proste CRUD-y i nieskomplikowane formularze | Szybki start, mało klas, łatwe do zrozumienia | Kod zaczyna się rozlewać, gdy reguł przybywa |
| Service Layer | Gdy trzeba uporządkować przypadki użycia i transakcje | Oddziela wejścia od reguł, zmniejsza duplikację | Może urosnąć do „grubych serwisów”, jeśli wszystko wrzucisz do jednej klasy |
| Domain Model | Złożona domena, dużo zasad i wyjątków | Reguły żyją blisko danych, łatwiej je testować i utrzymywać | Wymaga dyscypliny, bo łatwo wrócić do anemicznego modelu |
| Repository | Gdy chcesz odciąć logikę od technologii persystencji | Izoluje bazę danych i upraszcza zmianę technologiczną | Zbyt ogólne repozytoria robią abstrakcję, która niczego nie upraszcza |
Najbardziej praktyczny układ, jaki widzę w realnych projektach webowych, to połączenie cienkiego Service Layer z sensownie zbudowanym modelem domenowym. Serwis koordynuje przypadek użycia, a model pilnuje reguł. To ważne rozróżnienie, bo serwis ma wiedzieć co ma się stać, ale nie powinien przejmować całej odpowiedzialności za to, dlaczego to jest dozwolone.
Warto też uważać na anemiczny model domenowy. To sytuacja, w której encje są tylko pojemnikami na dane, a cała inteligencja ląduje w serwisach. Efekt bywa kusząco prosty na początku, ale później dostajesz kod proceduralny udający architekturę obiektową.
Jak to wygląda w praktyce na przykładzie sklepu internetowego
Najłatwiej zrozumieć ten temat na checkoutcie, bo tam reguły szybko się mnożą. Mamy koszyk, adres dostawy, płatność, promocje, limity magazynowe i status zamówienia. To właśnie tu widać, czy logika jest dobrze odseparowana, czy została porozrzucana po całym projekcie.
Dodanie produktu do koszyka
Na poziomie UI użytkownik klika przycisk, ale decyzja nie powinna kończyć się na samym dopisaniu rekordu. Warstwa biznesowa może sprawdzić, czy produkt jest dostępny, czy nie przekroczono limitu sztuk na klienta i czy dany wariant jest aktywny. Dzięki temu ta sama reguła działa niezależnie od tego, czy żądanie przyszło z przeglądarki, aplikacji mobilnej czy integracji API.
Zastosowanie rabatu
Tu często wychodzi, czy system ma porządną logikę domenową. Kod rabatu może być jednorazowy, może działać tylko dla nowych klientów, może nie łączyć się z inną promocją. Gdy takie warunki lądują w kontrolerze albo w zapytaniu do bazy, bardzo trudno potem dodać kolejny wyjątek bez psucia poprzednich.
Przeczytaj również: Flyweight pattern - Optymalizacja pamięci w aplikacjach webowych
Finalizacja zamówienia
Na tym etapie przydaje się wyraźny przypadek użycia: pobierz dane, zweryfikuj reguły, utwórz zamówienie, zapisz je, wyślij zdarzenie lub komunikat. Ja zwykle pilnuję, żeby w tym miejscu nie było technicznego chaosu. Serwis orkiestruje cały proces, ale sam nie powinien decydować o każdej pojedynczej regule domenowej. To rozróżnienie bardzo pomaga, gdy później pojawia się integracja z płatnościami, zwroty albo częściowe anulowanie zamówienia.
Taki układ daje też konkretną korzyść testową. Możesz sprawdzić reguły bez odpalania przeglądarki, bez HTTP i bez pełnej bazy danych. W praktyce to skraca czas diagnozy błędów bardziej, niż wielu zespołom się wydaje.
Jakie błędy najczęściej psują architekturę
Tu nie ma wielkiej tajemnicy. Większość problemów zaczyna się od wygody, a nie od złych intencji. Kod ląduje tam, gdzie akurat było najprościej go dopisać, a po kilku sprintach nikt już nie pamięta, gdzie naprawdę obowiązuje dana reguła.
- Logika w kontrolerach - szybka do napisania, trudna do utrzymania. Kontroler powinien przyjąć żądanie i przekazać je dalej, nie rozstrzygać wszystkich szczegółów biznesowych.
- Walidacja domenowa w bazie - baza może pilnować integralności technicznej, ale nie powinna być jedynym miejscem, gdzie żyją zasady biznesowe.
- Za grube serwisy - jedna klasa od wszystkiego zwykle oznacza, że przypadki użycia i reguły zaczęły się mieszać.
- Duplikowanie reguł - jeśli to samo sprawdzenie istnieje w API, w panelu admina i w skrypcie batchowym, prędzej czy później coś się rozjedzie.
- Abstrakcje bez potrzeby - nie każdy projekt potrzebuje rozbudowanego DDD. Czasem lepszy jest prosty układ niż formalnie „czysta”, ale ciężka architektura.
Najgroźniejszy błąd jest jednak bardziej subtelny: trzymanie decyzji biznesowych w miejscu, które powinno tylko transportować dane. To wygląda niewinnie, dopóki nie trzeba zmienić jednej reguły w pięciu miejscach naraz.
Jak projektować reguły, żeby zmiany nie bolały
Jeśli zaczynam nowy moduł, patrzę na niego przez pryzmat zmian. Dobra architektura nie jest po to, żeby ładnie wyglądała na diagramie, tylko po to, żeby łatwo przyjmowała kolejne wymagania. Z tego powodu wolę prosty model, który można rozbudować, niż wielką strukturę zbudowaną na wyrost.
- Zacznij od przypadków użycia - spisz, co system ma robić, a nie tylko jakie ma mieć tabele.
- Oddziel decyzję od zapisu - najpierw policz i zweryfikuj reguły, dopiero potem zapisuj wynik.
- Trzymaj reguły blisko modelu - jeśli obiekt „zamówienie” sam wie, kiedy można zmienić status, kod staje się czytelniejszy.
- Testuj logikę bez UI - test jednostkowy powinien sprawdzać zasadę biznesową, a nie to, czy strona się wyrenderowała.
- Nie bój się prostoty - jeśli domena jest mało złożona, transaction script albo niewielka warstwa usług mogą wystarczyć.
Ja szczególnie cenię zasadę, że każda reguła, która może się zmienić niezależnie, powinna mieć własne miejsce w kodzie. To nie oznacza od razu osobnej klasy dla wszystkiego, ale oznacza świadome myślenie o odpowiedzialności. Gdy taka reguła siedzi w jednym, przewidywalnym miejscu, łatwiej ją znaleźć, przetestować i zmienić bez efektu domina.
Po czym poznasz, że warstwa domenowa jest ułożona sensownie
Dobry znak jest prosty: nie musisz przekopywać się przez pięć plików, żeby odpowiedzieć na jedno pytanie biznesowe. Jeśli chcesz wiedzieć, kiedy zamówienie może przejść do płatności, szukasz jednej logiki, a nie ścieżki przez kontroler, usługę, helper, middleware i fragment SQL-a. To właśnie taki rodzaj czytelności robi największą różnicę w utrzymaniu systemu.
Sprawdzałbym przede wszystkim cztery rzeczy. Po pierwsze, czy reguły są testowalne bez infrastruktury. Po drugie, czy serwisy nie zaczęły same być miejscem wszystkich decyzji. Po trzecie, czy repozytoria tylko pobierają i zapisują, zamiast udawać miejsce na biznes. Po czwarte, czy nazwy klas i metod opisują realne działania z domeny, a nie techniczne przypadki użycia bez kontekstu.
Jeśli te warunki są spełnione, masz solidną bazę pod dalszy rozwój. A jeśli nie, to lepiej poprawić to wcześniej, zanim kolejne wymagania zamienią kod w zbiór wyjątków i obejść.
