Doświadczenie eksperta Coderise · GovTech / EduTech · Finlandia
Modernizacja platformy do zarządzania wczesną edukacją w Finlandii
Trzy lata pracy w roli Software Architecta nad rozwojem domenowej platformy: od mikroserwisów i modelu danych po automatyzację dopasowania wniosków, testy oraz utrzymanie produkcji.
- 3 lata
- pracy w roli Software Architecta przy rozwoju produktu
- DDD
- architektura mikroserwisów i model danych zgodne z domeną
- E2E
- testy pełnych scenariuszy i integracji systemu
Punkt wyjścia
Działający produkt wymagał nowego kierunku architektonicznego.
Platforma obsługiwała złożone procesy związane z wczesną edukacją: od przyjęcia wniosku i wstępnego dopasowania placówki po decyzje, opłaty, obecności i konta użytkowników. Zespół przejął system rozwijany wcześniej przez zewnętrznego dostawcę, a zastana architektura i model bazy danych utrudniały dalszy rozwój.
Zadaniem Software Architecta było wyznaczenie kierunku modernizacji oraz uzgadnianie decyzji technicznych z potrzebami produktu. Praca obejmowała zarówno projektowanie, jak i rozwój kodu, code review, uzgodnienia z Product Ownerami oraz wsparcie zespołów backendowych i frontendowych.
Modernizacja
Domena stała się punktem odniesienia dla kodu i danych.
Refaktoryzacja nie ograniczała się do porządkowania klas. Obejmowała sposób podziału odpowiedzialności, model relacyjny oraz reguły współpracy między modułami.
- 01
Granice domen
Procesy biznesowe porządkowano wokół czytelnych granic odpowiedzialności zgodnych z DDD.
- 02
Mikroserwisy
Rozwiązania projektowano tak, aby odpowiedzialności poszczególnych części produktu pozostawały wyraźnie rozdzielone.
- 03
Model danych
Strukturę bazy PostgreSQL refaktoryzowano w kierunku modelu lepiej odzwierciedlającego domenę.
- 04
Bezpieczne zmiany
Migracje Flyway oraz testy ograniczały ryzyko wprowadzania zmian w aktywnie używanym systemie.
Automatyzacja domenowa
System przygotowywał propozycje, a ostateczną decyzję podejmował operator.
Jednym z rozwijanych obszarów był preplacement — wstępne dopasowanie dzieci do placówek. Mechanizm analizował parametry wniosku i kryteria procesu, a następnie automatycznie dopasowywał oraz klasyfikował propozycje placementu.
Celem nie było zastąpienie człowieka w procesie administracyjnym. Operator otrzymywał uporządkowany materiał do analizy, dzięki czemu mógł poświęcić mniej czasu na ręczne zestawianie wniosków i skupić się na weryfikacji oraz wydaniu właściwej decyzji.
- 01Wniosekparametry i kryteria procesu
- 02Dopasowaniereguły domenowe preplacement
- 03Klasyfikacjauporządkowane propozycje
- 04Decyzja operatoraweryfikacja i zatwierdzenie
Zakres domenowy
Praca obejmowała kluczowe etapy obsługi wniosku i pobytu.
preplacementWstępne dopasowanie
Przygotowanie i klasyfikowanie propozycji placówek przed właściwym placementem.
placementUmieszczenie w placówce
Obsługa procesu przypisania dziecka do wybranej placówki edukacyjnej.
decisionDecyzje
Procesy prowadzące od danych wniosku do formalnej decyzji operatora.
decision paymentDecyzje o opłatach
Logika domenowa związana z przygotowaniem i obsługą decyzji dotyczących opłat.
attendanceObecności
Rejestrowanie oraz przetwarzanie informacji o planowanym i rzeczywistym pobycie.
accountsKonta
Zarządzanie kontami użytkowników platformy.
Jakość i dostarczanie
Założenia architektoniczne weryfikowano w działających scenariuszach.
Zmiany były zabezpieczane testami jednostkowymi, integracyjnymi i end-to-end tworzonymi przy użyciu JUnit 5 oraz Spock Framework. Maven i Flyway zapewniały powtarzalny build oraz kontrolowaną ewolucję bazy danych.
Testy integracyjne
Weryfikacja współpracy komponentów i infrastruktury.
Scenariusze E2E
Kontrola pełnych ścieżek najważniejszych procesów domenowych.
Google Cloud i CI/CD
Automatyczne dostarczanie oraz monitoring środowiska produkcyjnego.
Decyzje produktowe
Uzgadnianie kierunku rozwoju z Product Ownerami i programistami.
Efekt pracy
Modernizacja stworzyła stabilniejszą podstawę dalszego rozwoju platformy.
Czytelniejszy model domeny
Architektura oraz dane zostały ukierunkowane na konkretne procesy domenowe.
Mniej ręcznej analizy
Automatyczne propozycje wspierały operatorów podczas rozpatrywania wniosków.
Większa kontrola zmian
Testy, code review, migracje i monitoring zmniejszały ryzyko wprowadzania zmian.
Technologie
Stos wspierający rozwój systemu i utrzymanie produkcji.
- Java
- Spring Boot
- PostgreSQL
- Google Cloud
- Maven
- Flyway
- Spock Framework
- JUnit 5
- Testy integracyjne
- Testy end-to-end
- CI/CD
- Architektura mikroserwisowa
- Domain-Driven Design
Następny krok
Rozwijasz system, który przerósł swoją pierwotną architekturę?
Możemy zacząć od domeny, ograniczeń modelu danych i miejsc, w których zmiany są dziś najbardziej ryzykowne.