Egeria 8 – nowa technologia dla systemu klasy ERP
Podczas wytwarzania nowoczesnej i rozbudowanej aplikacji jaką jest system klasy ERP ( ang. Enterprise Resources Planning) - Egeria 8, bardzo ważnym elementem jest zdefiniowanie strategii, w oparciu o którą prowadzone będą prace. Ustalenie właściwej architektury systemu i założeń dla jej składowych jest kluczowe, ponieważ może zminimalizować czas jego wytworzenia, przy jednoczesnej maksymalizacji jakości.
Architektura systemu
Do implementacji aplikacji Egeria 8 wykorzystywana jest architektura mikrousług (ang. micro services), która pozwala na budowanie systemu jako zbioru przetestowanych, luźno powiązanych usług (mikroserwisów). Takie rozwiązanie umożliwia szybkie i niezawodne dostarczanie dużych i złożonych aplikacji, a także ich stosunkowo proste utrzymanie.Technologia mikroserwisów pozwala również pracować nad aplikacją kilku zespołom równocześnie. Każdy z nich może specjalizować się w odrębnej tematyce, dzięki czemu twórcy uzupełniają się nawzajem doświadczeniem, bez konieczności posiadania wiedzy na temat każdej dziedziny.
Podczas realizacji projektu wykorzystano kilka innowacyjnych podejść programistycznych. Każde z nich wynikło z wymagań stawianych przed budowanym systemem.
Domain-Driven Design
Domain-Driven Design to podejście do tworzenia oprogramowania, które kładzie nacisk na zrozumieniu domeny problemowej klientów. Ze względu na duże doświadczenie analityków Comarch w dziedzinie systemów klasy ERP, wyodrębniono adekwatne domeny – obszary, w których aplikacja ma być zastosowana. Następnie w obrębie danego obszaru tworzone są odpowiedzialne za niego mikrousługi.
Command Query Responsibility Segregation
Dodatkowo w Egerii stosowany jest wzorzec CQRS ( ang. Command Query Responsibility Segregation), który wprowadza rozdzielenie odpowiedzialności: rozkazów (ang. command) – czyli operacji, które modyfikują dane oraz zapytań (ang. query) –czyli operacji, które odczytują dane.
Wykorzystanie tego wzorca umożliwia niezależną optymalizację odczytu i zapisu, również dla zestawów danych, które wymagają obsługi wielu równoległych operacji. Ponadto w scenariuszach posiadających złożoną logikę biznesową, CQRS może uprościć zrozumienie domeny, dzieląc problem na części - modyfikacje i zapytania.
Convention Over Configuration
Kolejnym ważnym aspektem jest zwrócenie uwagi na dbałość zarówno o kod, jak i o konfigurację. Przy wprowadzaniu kolejnych nowych narzędzi stosowane są odpowiednie procedury sprawdzające ich przydatność i poprawność działania. Podczas weryfikacji kodu koncentrujemy uwagę na jakość wytworzonego kodu. Innymi słowy, stosowana jest praktyka COC ( ang. Convention Over Configuration). Jest ona często niedoceniana, jednak sukces frameworków, czy narzędzi o nią opartych np. Spring Boot, jest niezaprzeczalny
API-First Approach
Zastosowanie API-First Approach oznacza, że sam interfejs API ma fundamentalne znaczenie. Jeszcze przed rzeczywistą implementacją, wykorzystując język opisu API (ang. API description language), ustalane są kontrakty oraz sposób zachowania interfejsu. Dzięki temu projekt API jest lepiej przemyślany i zoptymalizowany, a czas jego wytworzenia niewiele dłuższy. Dodatkową zaletą jest fakt, iż zespoły backendowe i frontendowe mogą pracować równolegle, opierając się o stosowne kontrakty.
API Gateway oraz Backends For Frontends
W trakcie implementacji powstała konieczność wykorzystania kolejnego wzorca, jakim jest Brama Interfejsu (ang. API Gateway Pattern). Z naszego doświadczenia wynika, że pomimo właściwego podziału systemu na domeny, w niektórych sytuacjach pojawiają się komplikacje w zakresie mikroserwisów. Dzieje się tak wtedy, gdy żądanie wymaga informacji ze zbyt wielu mikroserwisów. W tym wypadku, aplikacja klienta musi wysyłać kilka żądań, a następnie integrować otrzymane informację ze sobą. Brama Interfejsu ogranicza liczbę operacji między klientami a usługami, gdyż odbiera ona żądania klienta i rozsyła do różnych serwisów na zapleczu, a następnie odsyła zagregowane wyniki. Dodatkowym atutem jest również możliwość odciążenia mikroserwisów od tzw. Cross-cutting concerns, którego przykładem może być uwierzytelnianie.
Kolejnym wyzwaniem jest rodzaj aplikacji klientów. Dla przykładu, użytkownik korzystający z witryny internetowej, nie będzie potrzebował tak kompleksowych informacji jak np. w przypadku zintegrowanego z Egerią 8 systemu. Z tego względu zdecydowano się na wykorzystanie dodatkowego wzorca Backends For Frontends, który jest wariacją wzorca Bramy Interfejsu. Działa on na bardzo podobnej zasadzie, więc dla każdego rodzaju klienta tworzona jest wspomniana brama. Takie rozwiązanie znacząco ogranicza czas oczekiwania podczas żądań oraz daje możliwość dodatkowej implementacji.
Jesteś ciekawy nowej odsłony ERP Egeria 8?
Wejdź na stronę: https://bit.ly/3o6jyVr, aby zaktualizować swoją wersję systemu lub zdecydować się na wdrożenie Egerii 8 w swojej organizacji.
