Architektura systemowa i wdrożeniowa są ortogonalne

Czy mikroserwisy to Bounded Contexty? Czy modularyzacja na poziomie architektury systemowej powinna wpływać na sposób wdrożenia? Co tak właściwie chcemy osiągnąć wprowadzając podziały na różnych poziomach architektury?

Granice systemowe

Termin architektura systemowa wskazuje, że wprowadzone w jej ramach podziały są niezwykle istotne. W końcu chodzi o podstawową strukturę naszego systemu. Czym jednak jest ta podstawowa struktura? Jakie są kryteria podziału na tym poziomie?

W większości biznesów domena jest na tyle duża, że trzeba nadać jej wewnętrzną strukturę. Dotyczy to działalności operacyjnej przedsiębiorstwa, powinno zatem dotyczyć również systemu tworzonego w celu wspierania tej działalności. Skoro tak, to podstawowymi podziałami powinny być na tym poziomie podziały biznesowe. Przykładowo chcemy oddzielić koncepcje biznesowe związane z wyceną produktów od tych związanych z ich magazynowaniem.

Istnieje wiele narzędzi, które pomagają nam we właściwym wprowadzaniu tego typu granic. Są nimi np. Bounded Contexty z Domain Driven Design. W tym momencie konkretne narzędzia nie są jednak istotne. Ważne jest to, że na poziomie architektury systemowej chodzi o nadanie struktury zgodnej ze strukturą biznesu. Nie jest to wcale trywialne zadanie. Proste mapowanie struktury organizacyjnej, albo innych cech widocznych na pierwszy rzut oka, zwykle nie sprawdza się zbyt dobrze.

Granice wdrożeniowe

W dyskusjach na temat wdrażania systemów przewijają się zwykle dwie podstawowe koncepcje: monolit i mikroserwisy. Albo wdrażamy system jako całość, albo każdą jego część osobno. Czym jednak są te części? Mikroserwisy, zgodnie z definicją, powinny być zorientowane biznesowo. Skoro tak, to odpowiedź powinna być prosta. Podziały z poziomu architektury systemowej powinny zostać przeniesione na poziom architektury wdrożeniowej. Przykładowo część systemu wspierająca wycenę powinna znaleźć się w jednym mikroserwisie, a część wspierająca magazynowanie w drugim. Ściślej rzecz biorąc ten dodatkowy poziom architektury przestaje być w ogóle potrzebny.

Tylko czy takie podejście jest faktycznie sensowne? Czy nie tracimy czegoś istotnego sprowadzając architekturę wdrożeniową do systemowej? Czy istnieją inne opcje wdrażania poza monolitem i mikroserwisami? Oczywiście tak! Należy się więc zastanowić, co chcemy osiągnąć wprowadzając granice na poziomie architektury systemowej i wdrożeniowej.

Co wpływa na system?

Żeby odpowiedzieć na pytanie po co w ogóle wprowadzać granice na dowolnym poziomie, trzeba zastanowić się, co właściwie wpływa na system. Czynniki takie określa się często jako drivery architektoniczne.

Czynników tych jest zazwyczaj bardzo wiele: od reguł i procesów biznesowych, przez wymaganą skalowalność i SLA, do kompetencji zespołu i otoczenia prawnego. Nie jest to jednak całkowicie nieustrukturyzowany zbiór. Dirvery architektoniczne możemy podzielić na różne kategorie np: funkcjonalne, techniczne, jakościowe, organizacyjne, etc.

Co chcemy zoptymalizować?

Skoro na system oddziałuje wiele czynników, to wszystkie one powinny zostać wzięte pod uwagę przy projektowaniu architektury. Skoro są one różnego rodzaju, to najprawdopodobniej nie zoptymalizujemy systemu pod ich kątem za pomocą jednego narzędzia.

Na poziomie architektury systemowej zajmujemy się driverami funkcjonalnymi i staramy się jak najlepiej dostroić strukturę systemu do naszej aktualnej wiedzy o biznesie. Na poziomie architektury wdrożeniowej zajmujemy się innymi kategoriami driverów np. jakościowymi, czy organizacyjnymi. Przykładowo jeżeli część odpowiedzialna za wycenę chcemy rozwijać z maksymalną swobodą, lub obciążenie może zmieniać się w niej bardzo dynamicznie, to warto jest wdrażać ją niezależnie od reszty systemu. Dzięki temu możliwe jest niezależne skalowanie nie tylko przepustowości, ale również procesu wytwarzania. Reszta systemu może jednak spokojnie zostać w modularnym monolicie.

Podziały systemowe nie zoptymalizują naszego systemu pod kątem niezależności wdrożeń, czy skalowalności. Podziały wdrożeniowe nie są konieczne do zapewnienia struktury systemu zgodnej ze strukturą biznesem.

Ortogonalność

Architektura systemowa i wdrożeniowa są ortogonalne, gdyż skupiają się na optymalizacji systemu pod kątem innych kategorii driverów. Sprowadzanie jednaj z nich do drugiej, lub mieszanie ich odpowiedzialności nie przyniesie nic poza bałaganem pojęciowym, a w konsekwencji błędnymi i niestety bardzo kosztownymi decyzjami.

Architektura systemowa i wdrożeniowa to osobne widoki architektoniczne. Projektując system potrzebujemy wielu tego typu widoków, żeby osobno rozpatrzyć różne aspekty systemu i wprowadzić granice, które będą odpowiedzią na faktyczne drivery architektoniczne.