Dobra architektura nie musi być kosztowna - wnioski

Architektura nie musi być kosztowna, trzeba tylko podejść do jej tworzenia w rozsądny sposób. Istotne żeby nie popaść w over-engineering z jednej strony i kompletny chaos z drugiej. Na szczęście są zasady i narzędzia, które mogą nam w tym istotnie pomóc.

Kluczowe jest poznanie biznesu

Projektowanie architektury abstrahując od biznesu jest błędem i prawie na pewno skończy się niepowodzeniem. To wiedza biznesowa pozwala nam właściwie zmodularyzować system. To on również umożliwia dobranie odpowiednich środków architektonicznych do każdej z części oraz to metod ich integracji.

Podejście takie to nic innego jak Domain Driven Design, w którym najważniejszy jest proces uczenia się. Działający kod jest, jak to określił Alberto Brandolini, jedynie efektem ubocznym.

Architektura powinna wspierać podejście Domain First

Przyczyną powstawania każdego systemu jest złożona wiedza biznesowa specyficzna dla przedsiębiorstwa. Systemy, które jej nie posiadają łatwiej kupić gotowe, niż inwestować we własne rozwiązanie.

Skoro model naszej domeny jest tym co najważniejsze w systemie, to nasza architektura powinna przede wszystkim wspierać możliwość przeprowadzania szybkich zmian i eksperymentów w tym obszarze. Aby to osiągnąć konieczne jest całkowite odseparowanie kodu modelującego domenę od technologii. Architekturą tego typu, sprawdzającą się świetnie tam, gdzie mamy głęboki model, jest Hexagonal / Clean / Architecture.

Architektura to nie technologia

Czasami architektura wiąże się z zastosowaniem określonych technologii, ale częściej jest czymś co pozwala abstrahować od technologii i skupić się na tym co naprawdę istotne. Technologia to tylko narzędzie i dobrze jest o tym pamiętać szczególnie na początku projektu.

Dopiero zrozumienie biznesu pozwoli nam na właściwy dobór technologii. To często wymaga czasu i eksperymentów. Dobrze więc żeby architektura wspierała ten proces, a nie była jego ograniczeniem.

Nie cały system musi mieć identyczną architekturę

Unifikacja na siłę jest przyczyną powstawania systemów, w których zrobienie prostych rzeczy wiąże się z pisaniem dużej ilości powtarzalnego kodu, a do zrobienia trudnych rzeczy i tak brakuje wystarczająco dobrze dopasowanych narzędzi. Mamy tu więc klasyczny kompromis, czyli sytuację w której wszyscy są niezadowoleni.

Znacznie lepszym podejściem jest dopasowywanie środków do konkretnych potrzeb. Standaryzacja ma sens jedynie w obrębie jednej techniki implementacyjnej. Ogromnie ważny jest tu również czynnik ludzki. Przyjęte standardy mają służyć zespołowi z takimi kompetencjami i preferencjami jakie posiadają jego członkowie. Zbyt duża standaryzacja między zespołami przyniesie znacznie więcej złego niż dobrego.

Architektura powinna się rozwijać razem z systemem

Przyszłość nie jest znana, a nasze rozumienie biznesu stale będzie się zmieniać. Architektura powinna nadążać za tymi zmianami, a nawet więcej powinna je wspierać. Nie bójmy się więc zmian w architekturze. Jeżeli coś wbrew oczekiwaniom okazało się proste, to zrezygnujmy z nadmiarowych warstw, CQRSa, czy jakiejkolwiek innej techniki. Jeżeli coś wymaga bardziej wyrafinowanych środków to wprowadźmy je, ale dopiero gdy okaże się to biznesowo potrzebne.

Nie wszystko trzeba mieć od razu. Zarówno style architektoniczne jak i technologie da się wprowadzać stopniowo. Warunkiem jest tu modularyzacja i właściwe zarządzanie zależnościami. Bez tego każdy system zamieni się w niemodyfikowalne spaghetti.

Seria – Architektura nie musi być kosztowna

Zapraszam do lektury pozostałych postów z tej serii:

1. Wstęp
2. Co to jest dobra architektura ?
3. Od czego zacząć projektowanie dobrej architektury ?
4. Architektura wspierająca podejście Domain First
5. Wnioski