
Interface-Oriented Design czyli architektura systemu zorientowana na interfejsy
Wprowadzenie
Tym razem krótka recenzja pewnej książki z roku 2006, a raczej jej polecenie każdemu projektantowi i architektowi dzisiaj. Na końcu polecam także kolejną nowszą pozycję jako uzupełnienie. Adresatami tej recenzji są głównie analitycy i projektanci, jednak adresuję ten wpis także do developerów, zakładam że dla nich nie jest to „coś nowego”, ale być może mają jakieś rady dla projektantów.
Warto także podkreślić, że pomiędzy OOP a OOAD jest coraz większa różnica i podział na role: analiza i projektowanie oraz implementacja, a także postępująca separacja tych ról, stają się standardem w inżynierii oprogramowania :
Programming is not solely about constructing software — programming is about designing software.
Kolejna warta zwrócenia uwagi rzecz: projektowanie integracji systemów w organizacji to nic innego model systemu zorientowany na interfejsy (patrz wcześniejszy wpis: Integracja systemów ERP jako źródło przewagi rynkowe).
Recenzja
Interface-Ofriented Design , to książka o architekturze i jej projektowaniu. We wstępie autor pisze (oryg):

Autor, na wielu przykładach pokazuje jak można projektować (tworzyć) oprogramowanie budując je ze współpracujących komponentów.
Wiele się mówi o programowaniu obiektowym a mało o projektowaniu zorientowanym na komponenty (moduły). Ważna rzecz: projektowanie zorientowane na interfejsy koncentruje się na komponentach i ich interfejsach, komponenty te mogą, ale nie muszą, być implementowane za pomocą języków obiektowych. Projekty, które skupiają się na komponentach i ich interfejsach mają ogromną zaletę: precyzyjnie opisują co ma program robić a jednocześnie nie narzucają narzędzia implementacji.
Kolejna rzecz to fakt, że obecnie znacznie bardziej niż w czasach gdy książka była pisana (ukazała się w 2006 roku), nabiera znaczenia rozproszona architektura: realnie nie ma już monolitów, mamy integracje systemów między partnerami handlowymi, z rejestrami publicznymi, między lokalnymi i chmurowymi infrastrukturami. Rozproszone przetwarzanie to architektury zorientowane na usługi, które kładą szczególny nacisk na interfejsy.
Interfejsy mogą być zorientowane na procedury (takie jak zdalne wywołania funkcji) lub na dokumenty (serwisy internetowe i integracje z protokołem RESTful API). Autor opisuje także wzorce i metody projektowania bazujące na luźnych powiązaniach, które są kluczowe dla budowania systemów rozproszonych. Więcej o interfejsach zorientowanych na dokumenty w moich projektach,
Ważna rzecz, na którą autor także zwraca szczególną uwagę: dziedziczenie jest często trudną do osiągnięcia techniką, jest to także często jedna z najbardziej nadużywanych cech języków obiektowych. Nacisk autora na interfejsy może wydawać się nieco ekstremalny, jednak (świeże w 2006 roku) spojrzenie na projektowanie architektury zorientowane na komponenty i ich odpowiedzialność, daje zaskakująco dobre efekty, a pamiętajmy, że generalnie liczy się cykl życia aplikacji czyli koszty jej utrzymania i rozwoju, a nie samo jej wytworzenie. Warto pamiętać, że dziedziczenie z zasady łamie zasadę hermetyzacji i jest zastępowanie stosowaniem szablonów lub po prostu rezygnuje się z tej techniki na rzecz agregatów.
Podsumowując: Kluczowym przesłaniem autora jest „odejście” od „programowania obiektowego” (orientacja kodu na dziedziczenie oraz łączenie funkcji i danych w obiekty, OOP) na rzecz „projektowania zorientowanego na niezależne, luźno powiązane komponenty” (polimorfizm i hermetyzacja), cechującego się pełną separacją komponentów, luźnymi powiązaniami (tylko wywołania operacji) i pojedynczą odpowiedzialnością (OOAD). Autor zwraca uwagę na sprawdzone wzorce, kluczowe: to fabryka (zwana także metodą wytwórczą, jest to separacja metod tworzenia obiektów od ich utrwalania), adapter (separacja współpracujących komponentów o niedopasowanych interfejsach). Co do zasady też (wzorce) separujemy przetwarzanie danych od ich samych (wzorzec repozytorium ). Dzisiaj dominujące są więc mikro serwisy i mikro aplikacje, natomiast łączenie danych i metod je przetwarzających w jednej klasie to antywzorzec.
Początek lat 2000 to nie tylko manifest Agile, to także już kilka lat po nim, nawoływanie sygnatariuszy Agile do porządku w inżynierii oprogramowania . Poza omawianą tu książką pojawiły się, w tamtym okresie, między innymi opis budowy komponentowej architektury , opis projektowania zorientowanego na odpowiedzialność komponentów .
Autor zwraca także szczególną uwagę na dokumentowe modele budowy interfejsów i integracji. Dokumentowe czyli zorientowane na przekazywanie między komponentami całych agregatów danych (zwanych dokumentami) zamiast wyników działania poszczególnych funkcji. Znakomicie upraszcza to architekturę, powoduje mniejsze uzależnienia, w konsekwencji cykl życia takiego systemu jest znacznie tańszy. O tym aspekcie architektury integracji pisał także znany autor Martin Fowfer .
Zachęcam do lektury tej książki, porządkuje wiedzę, być może wielu z Was znajdzie coś nowego. Od siebie powiem, że podejście takie stosuję od czasów lektury Systemów zorientowanych komponentowe Souzy, czyli od ponad 15 lat…
Doskonałym i aktualnym uzupełnieniem tej książki jest napisana później Czysta architektura :
Dobrzy architekci ostrożnie oddzielają szczegóły od reguł biznesowych, robiąc to tak dokładnie, że reguły te nie mają żadnej wiedzy o szczegółach i w żaden sposób od nich nie zależą. Dobrzy architekci tak projektują reguły systemu, żeby wszystkie decyzje dotyczące szczegółów można było podejmować tak późno, jak to tylko możliwe.
Źródła

BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Bardzo ciekawy artykuł o komponentach i konsekwencji niestosowania wzorców:
https://code.pieces.app/blog/how-to-refactor-large-react-components