Komponent to najmniejsza jednostka wdrożeniowa programu lub systemu.
Jest to zgrupowanie powiązanych klas i modułów, które są wdrażane, wersjonowane i zarządzane razem.
Komponentem może być na przykład:
- paczka NPM
- biblioteka JAR
- moduł w monorepo
- osobny mikroserwis
Spójność komponentów:
Reuse/Release Equivalence Principle(REP) – zasada istotności numeru wydania
Zasada mówi, że jednostką ponownego użycia jest jednostka wydania.
Oznacza to, że każda zmiana w komponencie powinna wiązać się z wydaniem nowej wersji komponentu.
Każdy komponent:
- posiada numer wersji,
- posiada dokumentację lub changelog, który opisuje, co zmieniło się w danej wersji,
- jest wydawany jako spójna całość.
Dzięki temu programista korzystający z komponentu sam decyduje, kiedy przechodzi na nowszą wersję, a zmiany w komponencie nie wymuszają natychmiastowych modyfikacji w całej aplikacji.
Common Closure Principle (CCP) – zasada wspólnego domknięcia
CCP jest odpowiednikiem zasady SRP na poziomie komponentów.
W jednym komponencie powinny znajdować się klasy, które mają ten sam powód do zmiany.
Dzięki temu, gdy zmienia się jedna reguła biznesowa, modyfikujemy jeden komponent, a nie wiele klas rozsianych po całej aplikacji.
Jeżeli zmiana jednego wymagania powoduje: commity w 5 komponentach, prawdopodobnie CCP jest złamane.
Common Reuse Principle(CRP) – zasada wspólnego użycia
Zasada mówi, że klasy, które są używane razem, powinny być umieszczone w tym samym komponencie.
Jednocześnie nie powinniśmy zmuszać użytkowników komponentu do zależności od klas, których nie potrzebują.
Jeżeli komponent zawiera wiele niepowiązanych funkcjonalności, każda zmiana w nim może wymusić aktualizację wersji, nawet wtedy, gdy używana jest tylko niewielka jego część.
Podsumowanie
Najważniejsze jest to, że nie da się jednocześnie maksymalnie spełnić wszystkich trzech zasad: REP, CCP i CRP.
Na początku życia projektu zazwyczaj większy nacisk kładzie się na CCP, ponieważ częste zmiany biznesowe wymagają łatwego modyfikowania kodu.
Wraz z rozwojem systemu coraz większego znaczenia nabiera REP, ponieważ stabilność, wersjonowanie i możliwość kontrolowanego aktualizowania komponentów stają się kluczowe.
Projektowanie komponentów to zawsze świadomy kompromis, a nie ślepe trzymanie się jednej zasady.