Kontekst
System C2W powstał jako inicjatywa typu “startup”, realizowana przy współpracy kilku podmiotów prywatnych.
Celem projektu było stworzenie rozwiązania klasy MVP umożliwiającego rozpoznanie rynku w zakresie rozliczania czasu pracy pracowników połączonego z geolokalizacją.
Architektura wysokopoziomowa
Z uwagi na techniczne implikacje (m.in. konieczność dostępu do dokładnej lokalizacji) przyjęto, że powstać musi system rozproszony, z dwiema aplikacjami klienckimi:
Przeznaczoną dla administratora / kierownika - oferującą szeroki dostęp do przeglądania, edycji i raportowania z danych za pośrednictwem interfejsu webowego,
Przeznaczoną dla pracownika aplikacją mobilną, która zawiera minimalny zakres funkcjonalności potrzebnych do rejestracji czasu pracy i odbierania powiadomień Push.
Obie aplikacje miały za pośrednictwem API opartym o protokół HTTP wymieniać dane ze współdzieloną częścią serwerową rozwiązania.
Ponieważ rozwiązanie z definicji miało umożliwiać obsługę wielu niezależnych podmiotów (multi-tenant) przyjęto, że wydzielony zostanie komponent realizujący wzorzec gateway umożliwiający w przyszłości realizację load-balancingu i/lub partycjonowania danych poszczególnych tenantów.
Poszczególne “kwanty" architektury całego rozwiązania przedstawia poniższy diagram UML (można go rozumieć tak jak diagram kontenerów według nomenklatury C4, a ich krótki opis zawiera lista pod diagramem:
Terminal Pracownika - Aplikacja mobilna pełniąca rolę terminala umożliwiającego pracownikom rejestrację pracy w danej strefie oraz reagowanie na generowane przez system powiadomienia typu Push obsługiwane przez urządzenie mobilne (iPhone / Android),
Panel Web - Aplikacja dostępna z poziomu przeglądarki umożliwiająca administratorom i kierownikom zarządzanie konfiguracją rozwiązania, przypisywaniem grafików, rozliczaniem i kontrolowaniem pracy,
Przystawka Administracyjna - Rozwiązanie umożliwiające prowadzenie powtarzalnych prac administracyjnych, monitorowanie aktywności użytkowników, zarządzanie licencjami itp.
Brama API - rozwiązanie realizujące wzorzec gateway (https://martinfowler.com/articles/gateway-pattern.html), ułatwiające w przyszłości rozbudowanie infrastruktury o skalowanie, load balancing oraz partycjonowanie tenantów,
Host Modułów Aplikacji - aplikacja enkapsulująca w sobie logikę aplikacyjną i biznesową poszczególnych modułów rozwiązania (zagadnienie modułowości poruszone będzie dalej),
Baza Danych - centralna baza danych rozwiązania umożliwiająca poszczególnym modułom przechowywanie ich danych.
Jako główny styl architektoniczny przyjęto styl modularnego monolitu jako podatny na ewentualną ewolucję w kierunku innych, bardziej wyspecjalizowanych stylów architektonicznych.
Postanowiono zatem system podzielić na szereg, dedykowanych, luźno powiązanych (z ang. loose coupling, high cohesion) ze sobą modułów:
Moduł główny / Core-owy - adresujący zagadnienia związane z administracją, dostępem oraz zarządzania strukturą organizacyjną,
Moduł planowania pracy - umożliwiający tworzenie i zarządzanie planami pracy,
Moduł raportowania pracy- umożliwiający realizację raportowania czasu pracy,
Moduł rozliczania pracy - umożliwiający automatyczne rozliczanie pracy, ręczną korektę i generowanie zestawień.
Implementacja każdego z takich modułów rozciągała się pomiędzy warstwy architektury systemu - obejmowała dedykowany moduł (w rozumieniu frameworka Angular) UI, dedykowany zestaw metod dostępowych API oraz strukturę bazy danych.
Poniższa ilustracja pokazuje wybrane zagadnienia tego podziału na przykładzie modułu rozliczeń.
Istotnym szczegółem jest fakt, że każdy moduł posiada dedykowany interfejs Web API - który umożliwia połączenie z warstwą prezentacji (panel Web lub terminal mobilny) - oraz kontrakt integracyjny udostępniany innym modułom. Ten ostatni to jedyny dozwolony w tym wypadku sposób umożliwiający modułom wymianę danych, co ma umożliwić ich dalszą ewolucję, zgodnie z ideą architektury ewolucyjnej.
Dodatkowym przyjętym ograniczeniem jest fakt, że struktury danych poszczególnych modułów muszą być całkowicie pozbawione referencji (w sensie typów obiektów danych reprezentujących je w kodzie aplikacji) oraz relacji (rozumianych jako mechanizmy zapewniające spójność danych np. kluczy obcych, choć baza SQL nie była tutaj użyta).
Takie ograniczenie ułatwia panowanie nad złożonością modułów i ułatwia dalszą ewolucję kodu.
Wszelkie zmiany wymagające koordynacji pomiędzy modułami komunikowane były poprzez zdarzenia obsługiwane synchronicznie lub asynchronicznie np.:
Potrzeba usunięcia struktur powiązanych z użytkownikiem po jego usunięciu,
Utworzenie pustego planu pracy dla nowych użytkowników,
Automatyczna aktualizacja rozliczenia w momencie zmiany planu lub pojawienia się nowych zdarzeń pracy.
W związku z powyższymi założeniami, główny ciężar i złożoność spoczywała na implementacjach logiki biznesowej uruchamianych po stronie serwera.
Strukturę kodu takiej implementacji na przykładzie wybranych elementów modułu Rozliczenia przedstawia poniższy diagram.
Stos technologiczny
Galeria
