Nuxeo dla pipeline'u kredytów hipotecznych: podejście low-code

Nuxeo w procesie obsługi wniosków o kredyt hipoteczny: low-code kontra mikroserwisy

Zespoły deweloperskie często wybierają architekturę mikroserwisów do obsługi potoku wniosków o kredyt hipoteczny — osobne usługi dla śledzenia statusów, przepływów pracy (workflow), dokumentów, audytu i orkiestracji. To prowadzi do problemów z integracją, rozproszonymi transakcjami oraz złożonością infrastruktury. Platforma low-code Nuxeo pozwala zaimplementować taki proces deklaratywnie, skupiając się wyłącznie na logice biznesowej — bez konieczności tworzenia dziesiątek niezależnych serwisów.

W Nuxeo wniosek o kredyt hipoteczny modelowany jest jako strukturalny dokument z metadanymi, cyklem życia i załącznikami. Jest to pojedynczy obiekt łączący plik, atrybuty klienta i wniosku, stany oraz przejścia między nimi.

Model dokumentu w Nuxeo

W Nuxeo dokument rozszerza podstawowy typ File, dodając niestandardowe schematy. Dla wniosku o kredyt hipoteczny definiujemy dwa schematy:

• mortgage_applicant: name (ciąg znaków), income (liczba zmiennoprzecinkowa), creditScore (liczba całkowita).
• mortgage_application: applicationNumber (ciąg znaków), requestedAmount (liczba zmiennoprzecinkowa), riskLevel (ciąg znaków), status (ciąg znaków), termMonths (liczba całkowita).

Typ dokumentu MortgageApplication dziedziczy zachowanie pliku i powiązuje oba schematy. Konfiguracja odbywa się wizualnie w Nuxeo Studio lub poprzez pliki XML w paczce JAR.

Przykład XSD dla mortgage_applicant.xsd:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:nxs="http://www.nuxeo.org/ecm/project/schemas/Test0124/mortgage_applicant" xmlns:nxsv="http://www.nuxeo.org/ecm/schemas/core/validation/" xmlns:ref="http://www.nuxeo.org/ecm/schemas/core/external-references/" targetNamespace="http://www.nuxeo.org/ecm/project/schemas/Test0124/mortgage_applicant">  
  <xs:element name="creditScore" type="xs:integer"/>
  <xs:element name="income" type="xs:double"/>
  <xs:element name="name" type="xs:string"/>
</xs:schema>

Analogicznie dla mortgage_application.xsd z polami wniosku. Rejestracja schematów w extensions.xml:

<extension target="org.nuxeo.ecm.core.schema.TypeService" point="schema">
    <schema name="mortgageapplication" prefix="mortgageapplication" override="true" src="data/schemas/mortgageapplication.xsd"/>
    <schema name="mortgage_applicant" prefix="appl" override="true" src="data/schemas/mortgage_applicant.xsd"/>
</extension>

To zapewnia silną typizację danych oraz możliwość ponownego wykorzystania schematów w różnych dokumentach.

Cykl życia wniosku: model deklaratywny

Cykl życia w Nuxeo składa się ze stanów (states) i przejść (transitions), które definiuje się w Studio. Dla wniosku o kredyt hipoteczny przyjmujemy następujące stany:

• Draft (Wersja robocza): utworzenie wniosku z załączeniem dokumentu wniosku.
• Submitted (Wysłany): weryfikacja załączników (dowód osobisty, numer PESEL, PIT-2) na podstawie nazw plików.
• Scoring (Ocena ryzyka): uzupełnienie dochodu, kwoty i oceny ryzyka; przejście automatyczne.
• Committee (Komisja kredytowa): obliczenie wskaźnika ryzyka i aktualizacja pola riskLevel.
• Approved/Rejected (Zatwierdzony/Odrzucony): decyzja podejmowana ręcznie przez pracownika.

Przejścia kontrolowane są natywnie przez platformę: rejestrowana jest pełna historia zmian, a dostępne działania są ograniczone do dopuszczalnych przejść. Nie ma potrzeby oddzielnego serwisu workflow — całość działa wbudowanym mechanizmem.

Automatyzacja przejść i walidacji

Przejście ze stanu Draft do Submitted następuje automatycznie po załączeniu wszystkich wymaganych dokumentów. W stanie Scoring uzupełniane są kluczowe pola, a uruchamiany jest proces oceny ryzyka. W stanie Committee wartość riskLevel obliczana jest na podstawie wprowadzonych danych.

W Nuxeo realizuje się to za pomocą:

• Automatycznych słuchaczy (listeners) reagujących na zmiany pól dokumentu.
• Reguł biznesowych definiowanych w Studio, określających warunki przejść.
• Wbudowanego audytu, który śledzi wszystkie zmiany stanów i wartości pól.

Platforma uniemożliwia niedozwolone przejścia, zapewniając przewidywalność działania bez konieczności implementowania rozproszonej logiki aplikacyjnej.

Korzyści dla programistów średnio- i starszego szczebla

Nuxeo minimalizuje boilerplate:

• Brak osobnych serwisów gateway, discovery czy tracing.
• Jedna spójna baza danych dla wszystkich dokumentów.
• Cykl życia (lifecycle) zastępuje złożoną orkiestrację przepływów.
• Schematy zapewniają silną typizację bez konieczności tworzenia DTO w kodzie źródłowym.

Ograniczenia: logika zaimplementowana wewnątrz platformy wymaga zrozumienia jej mechanizmów do skutecznej diagnostyki błędów. Dla zaawansowanych obliczeń (np. scoring kredytowy) można integrować zewnętrzny kod poprzez łańcuchy automatyzacji (automation chains) lub rozszerzenia w Javie.

Na co zwrócić uwagę:

• Nuxeo modeluje jednostki biznesowe jako dokumenty z cyklem życia — upraszcza to procesy związane z dokumentacją i przepływem dokumentów.
• Schematy i Studio pozwalają konfigurować strukturę danych bez pisania kodu, zachowując pełną typizację.
• Automatyczne przejścia i walidacje zastępują złożoną orkiestrację mikroserwisów.
• Idealne do zadań opartych na dokumentach; w przypadku czystych API lepiej stosować hybrydę z mikroserwisami.
• Pełna historia zmian i funkcje audytu są wbudowane i gotowe do użycia.

Skalowalność i integracja

Nuxeo obsługuje pracę w klastrze oraz udostępnia bogate REST API do integracji z zewnętrznymi systemami. W kontekście potoku wniosków hipotecznych:

• Interfejs użytkownika generowany jest automatycznie na podstawie modelu dokumentu.
• Przyciski „Zatwierdź” / „Odrzuć” wyświetlają się warunkowo, w zależności od bieżącego stanu wniosku.
• Obliczenia ryzyka mogą być realizowane przez słuchacz w Nuxeo lub zewnętrzny serwis (np. dedykowany moduł scoringowy).

Dzięki temu możliwe jest szybkie prototypowanie: od modelu do działającego prototypu w kilka godzin — nie tygodni.

— Editorial Team