Streamsoft Next


Architektura

Streamsoft Next


Architektura

Architektura

Streamsoft Verto „stworzony” na platformie Streamsoft Next jest systemem wielowarstwowym. Powszechnie wiadomo, że warstwy są dobre. System składa się z trzech głównych warstw fizycznych:

  • Warstwa danych
  • Warstwa logiki biznesowej
  • Warstwa prezentacji

Komunikacja pomiędzy warstwą biznesową a warstwą danych jest bardzo wydajna i odbywa się przy użyciu bibliotek i protokołów komunikacyjnych dostarczanych przez producentów baz danych. Dużo ciekawsza jest komunikacja pomiędzy warstwą logiki biznesowej a warstwą prezentacji. Tu używany standardowych protokołów internetowych HTTP, HTTPS. Konsekwencje są oczywiste, nie ma potrzeby używania terminali, protokołu RDP, system staje się wprost systemem internetowym.

Oprócz warstw, dzielących system w poziomie, platforma Streamsoft Next, narzuca korzystanie z dwóch stosów technologicznych, w formie podziału systemu zgodnego z innowacyjnym paradygmatem CQRS na stos komend i stos zapytań. Zastosowanie podejścia CQRS poprawia architekturę systemu i porządkuje ją pod względem odmiennej specyfiki przetwarzania dla każdego z tych typów zadań oraz wpływa na zwiększenie skalowalności warstwy danych i warstwy przetwarzania.

MSMaR

MSMaR to akronim od „Module, Service, Model and Runtime”, a to z kolei jest nazwą naszej autorskiej architektury systemowej. Główne założenia tej architektury to:

Module

  • System powinien składać się z odseparowanych modułów
  • Granice modułów powinny być wyznaczone poprzez zamknięty i kompletny zakres funkcjonalny
  • Moduły powinny dostarczać na zewnątrz wyłącznie serwisów i modeli

Service

  • Cała funkcjonalność systemu w zakresie realizacji zadań powinna być realizowana w postaci usług
  • Każda usługa posiada jasno zdefiniowany interfejs, stanowiący kontrakt
  • Dostęp do usług powinien być zunifikowany i oparty o uniwersalne protokoły

Model

  • System powinien jasno definiować własne, dziedzinowe komponenty składowe
  • System dla swoich komponentów powinien definiować klasy oraz uporządkowany zbiór instancji, stanowiących łącznie model komponentów systemu
  • Model systemu powinien być publiczny
  • Model systemu powinien być rozszerzalny zarówno o nowe instancje, jak i klasy

Runtime

  • System powinien posiadać przynajmniej jednego interpretatora modelu („runtime”)
  • „Runtime” powinien dostarczać systemowi kształtu wyłącznie na podstawie modelu
  • „Runtime” powinien dostarczać systemowi funkcjonalności wyłącznie na podstawie modelu i dostępnych usług
  • „Runtime” powinien być rozszerzalny

Umów bezpłatną prezentację systemu

Umów się z naszym konsultantem na bezpłatną prezentację systemu ERP.

Przedstawimy oferowane przez nas rozwiązania, dobrane pod kątem specyfiki branży, w której działa firma. Prezentacja jest jedną z najbardziej efektywnych form uzyskania informacji o możliwościach systemu ERP i korzyściach po jego wdrożeniu.

Wypełnij poniższy formularz:

Informacje o firmie

Nazwa firmy Branża Miejscowość

Dane kontaktowe

Imię i nazwisko Numer telefonu

Twoich danych użyjemy tylko do kontaktu z Tobą.

Dodatkowe informacje

W polu poniżej możesz zostawić wiadomość dla naszego konsultanta.