Bardzo podobały mi się koncepcje zawarte w filmie „Zasady czystej architektury” autorstwa wuja Boba Martina . Ale wydaje mi się, że ten wzór jest kombinacją wzorców Abstract Factory i Builder w jego rdzeniu.
Jest to jeden ze sposobów pisania dobrych programów, ale nie jedyny.
Railsy i reagjs to 2 frameworki, które przychodzą na myśl, które nie promują tego rodzaju czystej architektury. Railsy oczekują, że logika biznesowa znajdzie się w modelach ( FatModels i SkinnyControllers ) i będzie reagować wewnątrz komponentów. Oba podejścia ściśle łączą logikę biznesową i kod frameworka .
Nie znajduję nic złego na żaden z 3 sposobów. Jest to wezwanie do sądu, aby wybrać dowolną.
Ale w tym filmie sugeruję, że czysta architektura powinna mieć wyraźną granicę między logiką biznesową a strukturami. Frameworki (web, android itp.) Powinny być wtyczkami podłączanymi do logiki biznesowej. Nawet subtelnie kpi z szyn w filmie.
Czy więc „Czysta architektura” Boba Martina jest praktyczną zasadą dla wszystkich architektur, czy jest to tylko jedna z opcji?
źródło
Odpowiedzi:
Chociaż „czysta architektura” jest w porządku i ma wiele zalet, należy pamiętać, że:
Czysta architektura to w dużej mierze zmiana marki i ewolucji pokrewnych podejść Roberta C. Martina, takich jak Architektura Cebulowa autorstwa Jeffreya Palermo (2008) i Architektura Sześciokątna („Porty i adaptery”) Alistaira Cockburna i innych (<2008).
Różne problemy mają różne wymagania. Czysta architektura i powiązane podejścia zamieniają rozdzielanie, elastyczność i inwersję zależności nawet na jedenaście, ale poświęcają prostotę. To nie zawsze jest dobry interes.
Prekursorem tych architektur jest klasyczny wzór MVC firmy Smalltalk. To rozplątuje model z interfejsu użytkownika (kontrolera i widoku), dzięki czemu model nie zależy od interfejsu użytkownika. Istnieje wiele odmian MVC, takich jak MVP, MVVM,…
Bardziej złożone systemy nie mają tylko jednego interfejsu użytkownika, ale prawdopodobnie wielu interfejsów użytkownika. Wiele aplikacji oferuje interfejs API REST, z którego może korzystać dowolny interfejs użytkownika, na przykład aplikacja internetowa lub aplikacja mobilna. To izoluje logikę biznesową na serwerze od tych interfejsów użytkownika, więc serwer nie dba o to, która aplikacja ma do niego dostęp.
Zazwyczaj serwer nadal zależy od usług zaplecza, takich jak bazy danych lub dostawcy zewnętrzni. Jest to całkowicie w porządku i prowadzi do prostej architektury warstwowej.
Architektura sześciokątna idzie dalej i przestaje rozróżniać frontend i backend. Każdy system zewnętrzny może być wejściem (źródłem danych) lub wyjściem. Nasz podstawowy system określa niezbędne interfejsy (porty) i tworzymy adaptery dla dowolnych systemów zewnętrznych.
Klasycznym podejściem do silnego oddzielania jest architektura zorientowana na usługi (SOA), w której wszystkie usługi publikują zdarzenia i zużywają je ze wspólnej szyny komunikatów. Podobne podejście zostało później spopularyzowane przez mikrousługi.
Wszystkie te podejścia mają zalety , takie jak ułatwienie testowania systemu w oderwaniu (poprzez zastąpienie wszystkich zewnętrznych systemów, z którymi się łączy, próbnymi implementacjami). Ułatwiają zapewnienie wielu implementacji dla jednego rodzaju usługi (np. Dodanie drugiego procesora płatności) lub wymianę implementacji usługi (np. Przejście z bazy danych Oracle do PostgreSQL lub przepisanie usługi Python w Go) .
Ale te architektury to Ferrari architektur: drogie i większość ludzi ich nie potrzebuje. Dodatkowa elastyczność Clean Architecture itp. Wiąże się z większym kosztem złożoności. Wiele aplikacji, a zwłaszcza aplikacji CRUD, nie korzysta z tego. Sensowne jest izolowanie rzeczy, które mogą się zmienić, np. Przy użyciu szablonów do generowania HTML. Mniej sensowne jest izolowanie rzeczy, które raczej nie ulegną zmianie, np. Zapasowa baza danych. To, co może się zmienić, zależy od kontekstu i potrzeb biznesowych.
Ramy przyjmują założenia dotyczące tego, co się zmieni. Na przykład React ma tendencję do zakładania, że konstrukcja i zachowanie komponentu zmieniają się razem, więc nie ma sensu ich rozdzielać. Niewiele frameworków zakłada, że możesz chcieć zmienić framework. W związku z tym frameworki powodują pewną blokadę. Np. Poleganie przez Rail na (bardzo opiniotwórczym!) Wzorze Active Record utrudnia zmianę strategii dostępu do danych na (często lepszy) wzorzec repozytorium. Jeśli twoje oczekiwania dotyczące zmian nie odpowiadają ramom, użycie innego szkieletu może być lepsze. Wiele innych platform internetowych nie przyjmuje żadnych założeń dotyczących dostępu do danych.
źródło
Nawet nie blisko.
Kiedy na to spojrzysz:
Patrzysz na projekt wykresu obiektowego. To dyktuje, co wie o czym. W tej historii brakuje tego, jak zbudowano ten wykres obiektowy. Przepraszam, ale nie znajdziesz tego tutaj. Nie ma wzmianki o budowie.
Możesz to wszystko zbudować bez abstrakcyjnych fabryk i konstruktorów. Wiem, bo to zrobiłem . Nawet nie chciałem ich unikać. Kocham ich. Po prostu nie potrzebowałem ich. Właśnie wykorzystałem przekazywanie referencji. Dependency Injection to wymyślny termin.
W rzeczywistości mógłbym zbudować wszystko, co widzisz na tym schemacie. Następnie wystarczy wywołać jedną metodę na jednym obiekcie, aby rozpocząć tykanie.
Teraz rzeczy muszą istnieć, zanim będziesz mógł je wrzucić do innych rzeczy. Zbadałem to tutaj i podałem mu ten słodki mały schemat:
Możesz to wszystko zbudować, nawet nie wychodząc
main().Polecam korzystanie z konstruktorów i fabryk, jeśli chcesz rozbić stos proceduralnych kodów konstrukcyjnych na niezłe fragmenty pojęć. Ale nie ma nic w czystej architekturze ani żadnej innej modnej architekturze, która wymagałaby tego. Więc jeśli chcesz się trzymać
main(), dobrze. Proszę, zmiłuj się .Uważam, że „Czysta architektura” to modne hasło, które prowadzi ludzi do bloga i książki. Ten blog i książka mają bardzo dobre wyjaśnienia bardzo podobnych starszych Architektur o starszych nazwach używanych do kierowania ludzi do starszych blogów i starszych książek. W szczególności cebula, a także porty i adaptery. Żadna z nich nie jest jedyną dostępną opcją architektoniczną.
Lubię wujka Boba, ponieważ jest niesamowitym mówcą i autorem. Sprawia, że myślę o rzeczach, których inaczej nie miałbym. Ale jeśli pozwolisz, aby zmieniło cię to w religijnego fanatyka, który nalega, aby wszystko zrobić po swojemu, szybko przekonasz się, że aktualizacja dokumentacji jest najbliższa, na którą pozwolę ci przejść do mojego kodu.
Architektury modnego hasła są przydatne, gdy masz długowieczny kod, który musi się utrzymywać, podczas gdy świat zmienia się wokół niego. Właśnie wtedy świeci. Jeśli świat jest stabilny w porównaniu z kodem, to robisz coś eleganckiego bez powodu.
Bez względu na to, jak niesamowite wydaje się coś, istnieje kontekst, w którym można go umieścić, co sprawi, że będzie to absurdalne. Przepraszam, to też nie jest srebrna kula.
Masz rację. On robi. Wujek Bob uważa, że frameworki można traktować jak biblioteki. I mogą. Ale nawet ta decyzja kosztuje cię coś.
To, co pan Martin stara się zachować, to przestrzeń, w której twój język ogólnego przeznaczenia jest nadal ogólny. Porzucisz to, gdy wszędzie rozpowszechnisz framework. Kiedy to zrobisz, zmierzasz w kierunku przekształcenia swojego języka w coś, co nazywa się językiem specyficznym dla domeny. HTML jest językiem specyficznym dla domeny. Wykonuje swoją pracę bardzo dobrze, ale są inne prace, których w ogóle nie można wykonać.
Tak długo, jak ramy będą przewidywać twoje potrzeby, wszystko pójdzie bardzo gładko. Miło jest przewidywać twoje potrzeby. To stawia Cię w pudełku, które upraszcza sprawę. Po prostu zrozum, co poświęcasz, aby to zdobyć. Jeśli rozpowszechniasz Spring wszędzie, nie możesz go już reklamować jako pracy Java. To praca Java / Spring. Mógłbym powiedzieć to samo o Ruby i Railsach, ale Rails już dawno zjadł lunch Ruby.
źródło
Aby zacytować wideo:
śledzony przez:
Architektura, podobnie jak scalanie poczty, jest tylko jedną z wielu opcji.
Nie opcjonalne są problemy, które architektura próbuje rozwiązać.
Jeśli zrozumiesz, jakie problemy powoduje korespondencja SQL w porównaniu z innymi rozwiązaniami, Twój wybór architektury zostanie poinformowany, a nawet jeśli będziesz zmuszony wybrać „złe” rozwiązania, będziesz świadom i eliminować ich niedociągnięcia.
Jeśli zastosujesz styl architektoniczny tylko dlatego, że jest dobrze przemyślany, prawdopodobnie popełnisz błędy i napotkasz te same problemy.
źródło
„Czysta architektura” jest zdecydowanie „tylko” jedną z opcji. Twierdziłbym, że jest to jedna ze złych opcji dla większości projektów, szczególnie dla projektów zorientowanych obiektowo.
Oto analiza zdanie po zdaniu artykułu wuja Boba na temat czystej architektury z uzasadnieniem powyższego stwierdzenia:
Czysta architektura z perspektywy obiektowej
źródło
Czysta architektura to zestaw zasad i wzorców służących do rozwiązania wielu typowych objawów, z jakimi często spotykają się organizacje opracowujące oprogramowanie przez cały czas tworzenia złożonych aplikacji. Martin dokłada wszelkich starań, aby zidentyfikować objawy i przyczyny w oparciu o swoje bogate doświadczenie w tej dziedzinie oraz wyjaśnić rolę architektury w łagodzeniu tych obaw.
Nie jest to jednak reguła kciuka ani panaceum na wszystkie bolączki. Jeśli czytasz książkę, będziesz lepiej rozumieć, czy / kiedy / jak stosować zasady i wzorce, które on popiera (oraz związane z tym kompromisy). Jeśli nie przeczytałeś książki, prawdopodobnie będziesz dokonywał nieprawidłowych założeń, wniosków, ocen i oświadczeń na podstawie niepełnych informacji.
źródło