Architektura komponentowa
to rodzaj architektury aplikacji składającej się z niezależnych,
modułowych i wielokrotnego użytku bloków konstrukcyjnych zwanych
komponentami.
Architektura oparta na komponentach skupia się na rozłożeniu projektu na poszczególne komponenty funkcjonalne lub logiczne, które reprezentują dobrze zdefiniowane interfejsy komunikacyjne zawierające metody, zdarzenia i właściwości.
Co to jest komponent?
Komponent to obiekt wielokrotnego użytku, który przyspiesza tworzenie i dostarczanie aplikacji oraz zapewnia dodatkowe funkcje.
Każdy komponent powinien realizować założoną funkcjonalność i dostarczać jej innym komponentom tylko za pośrednictwem własnego interfejsu. Posiada dobrze wyspecyfikowany interfejs oraz zachowanie.
Komponenty traktuje się jako twory generyczne. Dopiero zbiór takich połączonych ze sobą komponentów stanowi rzeczywistą aplikację.
Komponenty są jednym z najważniejszych aspektów low-code platform , ponieważ umożliwiają ponowne wykorzystanie kodu i repozytoriów bibliotek komponentów. W rezultacie programiści mogą tworzyć wysokiej jakości komponenty aplikacji i udostępniać je innym, przyspieszając czas tworzenia aplikacji i fragmentację kodu.
Komponenty są wieloaspektowe. Mogą służyć jako elementy infrastruktury dla Twojej fabryki,
dodane do więcej niż jednej aplikacji. Mogą również znajdować się w
publicznym repozytorium komponentów, dzięki czemu może z nich korzystać
wiele aplikacji i programistów. Opublikowanie ich w repozytorium pomaga
kilku osobom w wielu scenariuszach.
Rozwój oparty na komponentach zyskuje na popularności. I stanowi realną alternatywę dla wyboru między monolitem a mikroserwisami.
Typy komponentów
Dla różnych warstw aplikacji istnieją różne typy komponentów, w tym:
- Motywy, które
definiują wygląd i działanie aplikacji, poprzez szereg reguł arkusza
stylów oraz definicje siatki używane do pozycjonowania i rozmiaru
elementów na ekranie.
- Widgety lub Bloki, które
zapewniają dodatkowe funkcje wielokrotnego użytku, zwykle związane z
interfejsem użytkownika lub zdarzeniami. Aby stać się komponentami,
bloki muszą zawierać zestaw definicji, takich jak parametry i zmienne.
- Biblioteki, które
są owinięte wokół bloków i akcji, które zapewniają łatwy w interakcji
interfejs. Dobrym przykładem są biblioteki JavaScript, które oferują
świetny interfejs użytkownika.
- Łączniki, które
umożliwiają integrację bez konieczności pisania niestandardowego kodu,
znacznie redukując czas i wysiłek oraz eliminując błędy. Mówiąc
najogólniej, konektory umożliwiają integrację z innymi aplikacjami, np.
Facebook czy Paypal.
- Wtyczki, które są dodatkami, które są instalowane w programie, zwiększając jego możliwości.
Hybrydowe podejście między architekturą warstwową i opartą na funkcjach.
Komponenty mogą być dedykowane do konkretnych warstw aplikacji, takich jak back-end czy interfejs użytkownika
W architekturze warstwowej organizujemy poziome plastry. Liczba warstw może być różna w zależności od aplikacji. Generalnie mamy:
- Warstwa internetowa: obsługuje przychodzące żądania, renderuje HTML itp.).
- Warstwa biznesowa: egzekwowanie reguł biznesowych na danych
- Warstwa danych: łączy się z bazą danych w celu zapytania i aktualizacji danych.
Kiedy przychodzi prośba, idzie od góry do dołu.
W architekturze opartej na funkcjach organizujemy kod na podstawie tego, co robi z perspektywy funkcjonalnej. Jest to krojenie w pionie. Grupujemy razem kod związany z określoną funkcją.
Tylko kontroler jest wystawiony na świat zewnętrzny. Wszystko inne jest chronione pakietem: nie można wywołać spoza pakietu funkcji.
Ma większą spójność, ponieważ
cały kod jest w jednym miejscu. A jeśli funkcja jest uważana za
komponent, możemy łatwo dopasować kod do diagramów projektu, ponieważ
kod teraz odzwierciedla projekt architektury.
Architektura oparta na komponentach - Hybrydowe podejście między architekturą warstwową i opartą na funkcjach.
Zamiast warstwowego podejścia, poziomych wycinków, podzieliliśmy aplikację pionowo na modułowe komponenty, tak jak w przypadku architektury opartej na funkcjach.
Komponent w tym kontekście to grupa powiązanych funkcjonalności, które kryją się za ładnym i przejrzystym interfejsem.
Elastyczność między komponentami jest naprawdę ważna, ponieważ nie muszą wiedzieć o ich wewnętrznych działaniach. Komponenty po prostu komunikują się przez swoje interfejsy.
Zasady projektowania opartego na komponentach
Jeśli tworzysz składnik, który zawiera tylko logikę, rozważ utworzenie pustego modułu, aby nie zawierał zależności interfejsu użytkownika. Takie podejście sprawia, że komponent jest lekki i łatwiejszy do ponownego użycia.
Każdy komponent ma swój własny
interfejs, który określa wymagane porty i dostarczone porty; każdy
składnik ukrywa swoją szczegółową implementację.
Jeśli chodzi o koordynację w całym systemie, komponenty komunikują się ze sobą za pośrednictwem interfejsów. Gdy komponent oferuje usługi reszcie systemu, przyjmuje udostępniony interfejs,
który określa usługi, z których mogą korzystać inne komponenty, oraz
sposób, w jaki mogą to robić. Interfejs ten może być postrzegany jako
sygnatura komponentu - klient nie musi wiedzieć o wewnętrznym działaniu
komponentu (implementacji), aby z niego korzystać. Ta zasada skutkuje
komponentami określanymi jako kapsułkowane
Komponent powinien być rozbudowywany bez konieczności wprowadzania wewnętrznych modyfikacji kodu lub projektowania istniejących części komponentu.
Komponent może rozszerzać się na inne komponenty i nadal oferować własne punkty rozszerzeń. Jest to koncepcja architektury opartej na wtyczkach. Dzięki temu wtyczka może zaoferować inny interfejs API wtyczek.
Tworząc komponenty internetowe, promuj Reactive Web zamiast tradycyjnej sieci Web.
Zalety architektury komponentowej
- Komponenty mogą być wykorzystane w wielu aplikacjach.
- Każdy komponent może zawierać swoją własną konfigurację i być konfigurowany w różny sposób dla różnych aplikacji;
- Skraca czas budowy nowych aplikacji i obniża koszty projektu - poprzez zastosowanie istniejących komponentów
- Poszczególne komponenty mogą być tworzone równolegle.
- Poprzez dobre wyspecyfikowanie interfejsów poszczególnych komponentów można łatwo zlecać implementacje komponentów na zewnątrz;
- Wspiera tzw. modyfikowalność aplikacji - konkretna funkcjonalność skupia się w dedykowanych komponentach programowych więc w przypadku konieczności wprowadzenia zmiany, z reguły proces ten dotyczy modyfikacji jednego lub co najwyżej kilku komponentów a nie całej aplikacji.
- Tutaj warto zwrócić zatem uwagę na spójność funkcjonalną poszczególnych komponentów (ang. coherence). Spójność komponentów wspiera modyfikowalność - im większa spójność tym łatwiej modyfikować aplikację.
- Komponenty umożliwiają centralizację określonych fragmentów kodu. Ponieważ kod znajduje się w jednym miejscu, programiści mają nad nim większą kontrolę.
- Inną ważną cechą komponentów jest to, że są substytucyjne , dzięki czemu komponent może zastąpić inny (w czasie projektowania lub w czasie wykonywania), jeśli następca spełnia wymagania komponentu początkowego (wyrażone przez interfejsy). W związku z tym komponenty można zastąpić zaktualizowaną wersją lub alternatywą bez naruszania systemu, w którym działa składnik.
Materiały
http://architektura-oprogramowania.blogspot.com/p/architektura-komponentowa.html
https://www.outsystems.com/blog/posts/component-architecture/
https://medium.com/omarelgabrys-blog/component-based-architecture-3c3c23c7e348
https://files.gotocon.com/uploads/slides/conference_12/515/original/gotoberlin2018-modular-monoliths.pdf
Brak komentarzy:
Prześlij komentarz