6.1 Rozkład
Pomimo różnorodności kryteriów, głównym zadaniem w rozwoju dużych systemów jest zadanie zmniejszenia złożoności systemu . Aby zmniejszyć złożoność, nie wynaleziono jeszcze nic poza podziałem na części.
Czasami dla uproszczenia nazywa się to zasadą „dziel i zwyciężaj”, ale z punktu widzenia architekta oprogramowania mówimy o dekompozycji hierarchicznej .
Złożony system musi być zbudowany z niewielkiej liczby prostszych podsystemów, z których każdy z kolei składa się z mniejszych części i tak dalej, aż najmniejsze części będą wystarczająco proste, aby można je było bezpośrednio zrozumieć i stworzyć.
Wspaniałą wiadomością jest to, że jest to rozwiązanie nie tylko jedyne znane, ale również uniwersalne. Oprócz zmniejszenia złożoności zapewnia jednocześnie elastyczność systemu , dobrą skalowalność i zwiększoną odporność poprzez powielanie krytycznych części.
Odpowiednio, jeśli chodzi o budowanie architektury programu, tworzenie jego struktury, oznacza to dekompozycję programu na podsystemy, usługi, warstwy, podprogramy i moduły funkcjonalne oraz organizowanie ich interakcji między sobą i światem zewnętrznym.
A najcenniejsze jest to, że im bardziej niezależne są podsystemy, tym bezpieczniej jest skupić się na rozwoju każdego z nich z osobna w określonym momencie i nie martwić się o wszystkie pozostałe części.
6.2 Korzyści z architektury modułowej
Stosowanie zasady hierarchicznej dekompozycji pozwala pozbyć się chaosu w tysiącach klas Twojego kodu. Pamiętasz, że Twój kod jest podzielony na pakiety (pakiety) i podpakiety? Jest to jedno z wyrażeń dla rozkładu hierarchicznego.
Twój program zmienia się ze zbioru klas w zestaw bibliotek i modułów, które współdziałają ze sobą zgodnie z dobrze zdefiniowanymi i prostymi regułami. To z kolei pozwala zapanować nad jej złożonością, a także daje możliwość uzyskania wszystkich korzyści, które zazwyczaj kojarzone są z koncepcją dobrej architektury.
Oto najbardziej podstawowe:
- Skalowalność - możliwość rozbudowy systemu i zwiększania jego wydajności poprzez dodawanie nowych modułów.
- Łatwość konserwacji - zmiana jednego modułu nie wymaga wymiany innych modułów.
- Wymienność modułów (Swappability) - moduł można łatwo wymienić na inny.
- Testowanie jednostek – Jednostkę można odłączyć od wszystkich innych i przetestować/naprawić .
- Reusability - moduł może być ponownie wykorzystany w innych programach i innych środowiskach.
- Konserwacja - program podzielony na moduły jest łatwiejszy do zrozumienia i utrzymania.
Można powiedzieć, że rozbicie złożonego problemu na proste fragmenty jest celem wszystkich technik projektowych . A termin „architektura” w większości przypadków odnosi się po prostu do wyniku takiego podziału plus „niektóre decyzje projektowe, które raz podjęte są trudne do zmiany” (Martin Fowler „Architecture of Enterprise Software Applications”).
Dlatego większość definicji w takiej czy innej formie sprowadza się do:
„ Architektura identyfikuje główne komponenty systemu i sposób ich interakcji. To także wybór takich decyzji, które są interpretowane jako fundamentalne i nie podlegające zmianom w przyszłości ”.
„ Architektura to organizacja systemu, zawarta w jego komponentach, ich wzajemnych relacjach i z otoczeniem. System to zestaw komponentów połączonych w celu wykonywania określonej funkcji ”.
Zatem dobra architektura to przede wszystkim architektura modułowa/blokowa . Aby uzyskać dobrą architekturę, musisz wiedzieć, jak poprawnie rozłożyć system. Oznacza to, że konieczne jest zrozumienie, który rozkład jest uważany za „poprawny” i jak najlepiej go przeprowadzić.