Bartosz Milewski 
Większość systemów IT staje się trudna w utrzymaniu nie z powodu złego kodu, ale z powodu złego modelu domeny. Klasycznym błędem podczas zbierania wymagań i projektowania architektury w duchu Domain-Driven Design (DDD) jest opieranie granic systemu na tym, jak firma w danej chwili działa, zamiast na tym, co tak naprawdę robi.
Większość analityków i przedstawicieli biznesu jest naturalnie zorientowana na procesy i rezultaty (…) Twoim zadaniem jako projektanta czy architekta jest dostrzec te subtelne różnice. Słuchaj o procesach, ale destyluj z nich zdolności biznesowe.
Mylimy tutaj dwa fundamentalne pojęcia: „zdolność biznesową” oraz „proces biznesowy”.
Choć na spotkaniach z biznesem te terminy często przeplatają się ze sobą, w modelowaniu architektury pełnią zupełnie inne role. Niezrozumienie tej różnicy to prosta droga do stworzenia systemu, który posypie się przy pierwszej optymalizacji wprowadzanej przez firmę.
Przyjrzyjmy się bliżej tym pojęciom, aby uniknąć architektonicznych pułapek.
Zdolność biznesowa – czyli CO robimy?
Zdolność biznesowa to fundamentalna umiejętność, którą organizacja musi posiadać, aby osiągnąć swoje cele strategiczne. To odpowiedź na pytanie: Co firma potrafi robić?
Kluczową cechą zdolności biznesowych jest ich stabilność. Niezależnie od tego, jak zmienia się technologia czy trendy rynkowe, podstawowe zdolności firmy pozostają niezmienne.
Przykłady zdolności:
- Zarządzanie magazynem
- Obsługa płatności
- Fakturowanie
Sklep internetowy przyjmował płatności 10 lat temu, przyjmuje je dzisiaj i będzie to robił za dekadę. Zmienią się tylko narzędzia.
Znaczenie w DDD: W kontekście Domain-Driven Design to właśnie zdolności biznesowe są najlepszym kompasem do identyfikacji i definiowania granic Bounded Contextów (lub subdomen). Opierając moduł na stabilnej zdolności (np. Kontekst Płatności), zyskujesz pewność, że granice Twojego systemu nie zdezaktualizują się z dnia na dzień. Moduł staje się niezależnym, solidnym klockiem.
Proces biznesowy – czyli JAK to robimy?
Proces biznesowy to sekwencja działań, kroków lub decyzji podejmowanych w określonym czasie, aby osiągnąć konkretny wynik. To odpowiedź na pytanie: Jak to robimy tu i teraz?
Procesy są bardzo dynamiczne i ulotne. Zmieniają się za każdym razem, gdy firma optymalizuje koszty, automatyzuje pracę czy wdraża nową technologię.
Przykłady procesów:
- Księgowa ręcznie weryfikuje przelew i zatwierdza zamówienie.
- Klient klika „Kup”, system odpytuje bramkę PayU, a po sukcesie wysyła maila.
- Magazynier drukuje etykietę, pakuje paczkę i przekazuje ją kurierowi o 15:00.
Ten sam proces „obsługi wysyłki” za rok może wyglądać zupełnie inaczej – paczki mogą pakować roboty, a transport realizować drony. Cel zostanie ten sam, ale „JAK” ulegnie całkowitej zmianie.
Znaczenie w DDD: Jeśli oprzesz główne granice architektury na procesie, każda zmiana organizacyjna wywoła lawinę zmian w kodzie. Dlatego procesów biznesowych nie modelujemy jako Bounded Contextów. Modelujemy je jako przepływy (workflows), przypadki użycia (use cases), Sagi lub Process Managery. Proces to warstwa orkiestracji – dyrygent, który po prostu pociąga za sznurki stabilnych zdolności biznesowych w odpowiedniej kolejności.
Praktyczny przykład: Jak to wygląda w kodzie?
Wyobraźmy sobie e-commerce i proces: „Złożenie i realizacja zamówienia”.
Zamiast budować jeden wielki moduł OrderProcessing (który miesza logikę wszystkiego po trochu i jest wrażliwy na każdą zmianę), dzielimy system na niezależne zdolności biznesowe (Bounded Contexty):
- Katalog Produktów (zdolność: prezentacja oferty)
- Zamówienia (zdolność: zbieranie koszyka i wiązanie transakcji)
- Płatności (zdolność: pobieranie środków)
- Wysyłka (zdolność: dostarczenie towaru do klienta)
Proces biznesowy staje się w tym układzie jedynie koordynatorem (np. opartym o zdarzenia domenowe – Domain Events). Kiedy powstaje zamówienie, proces mówi:
Hej Płatności, pobierzcie pieniądze.
Gdy płatność się uda, proces mówi:
Hej Wysyłka, wygeneruj etykietę dla zamówienia X.
Jeśli biznes postanowi jutro odwrócić proces i najpierw pakować paczkę, a zapłatę pobierać u kuriera (za pobraniem) – nie musisz przepisywać logiki wysyłki ani płatności. Zmieniasz tylko proces (kolejność wywoływania klocków).
Heurystyka: Jak łatwo odróżnić zdolność od procesu?
1. Zdolności biznesowe lubią RZECZOWNIKI. Opisują strukturę, umiejętności i obszary.
- Przykłady: Zarządzanie klientami, Przetwarzanie zamówień, Fakturowanie, Obsługa zwrotów.
2. Procesy biznesowe lubią CZASOWNIKI. Opisują akcje, przepływ i sekwencje w czasie.
- Przykłady: Zweryfikuj status płatności, Utwórz zamówienie, Zaksięguj wpłatę, Wyślij przypomnienie.
Podsumowanie
Większość analityków i przedstawicieli biznesu jest naturalnie zorientowana na procesy i rezultaty. Na spotkaniach (np. podczas Event Stormingu) będą opowiadać Ci przede wszystkim o tym, jak pracują. Zdolności firmy często schodzą na dalszy plan lub są uznawane za „zbyt oczywiste”, by o nich mówić.
Twoim zadaniem jako projektanta czy architekta jest dostrzec te subtelne różnice. Słuchaj o procesach, ale destyluj z nich zdolności biznesowe. To właśnie te zdolności pozwolą Ci nakreślić właściwe granice modułów, a w efekcie – zbudować elastyczny system, który zamiast opierać się zmianom biznesowym, będzie na nie gotowy.