Czysta Architektura cz.1 – Wstęp, czyli teoria

Dzisiaj będzie trochę bardziej teoretycznie. Naświetlę co rozumiem pod hasłem “czysta architektura”, co się pod tym kryje. Na końcu będzie też link do prelekcji wujka Bob’a, od której się to u mnie wszystko zaczęło.

Na początek trochę o tym, co rozumiem pod pojęciem “czystej architektury”:

  1. Spełnia zasady SOLID,
  2. Po spojrzeniu na strukturę projektu, wiemy co nasza aplikacja potrafi (niekoniecznie w jakim jest framework’u).

Takie podejście praktycznie na wstępie eliminuję znane mi framework’i MVC, w których tworzy się wielkie kontrolery skupiające się wokół encji/modeli. Dodatkowo zazwyczaj okazuje się, że jeden kontroler musi korzystać z więcej niż jednej encji, w związku z tym jego zależności rosną.

Zastanawiałem się kiedyś, do czego porównać dobrze napisane oprogramowanie. Najlepszym porównaniem wydało mi się porównanie do dobrze zorganizowanej firmy. W firmie takiej występuje kilka reguł, które składają się na to, że firma jest dobrze prowadzona. Są to:

  • nikt nie jest niezastąpiony,
  • podział zadań pomiędzy poszczególne stanowiska jest jasny i czytelny,
  • komunikacja pomiędzy pracownikami jest skonstruowana w sposób przejrzysty i bez zbędnej biurokracji,
  • nad wszystkim czuwa szef/manager, który nie robi wszystkiego sam, ale zatrudnia na poszczególne stanowiska takie osoby, którym może spokojnie przekazać obowiązki i odpowiedzialność,
  • każdy pracownik posiada narzędzia, które są mu niezbędne do wykonywania powierzonej pracy.

Na diagramie 1, rozrysowałem przykład przedstawiający zorganizowaną według tych zasad pizzerię.
Diagram 1. Pizzeria

Widać na tym diagramie podział obowiązków, gdzie kucharz, który wykonuje “właściwą pracę” jest wspomagany przez pracowników wykonujących inne potrzebne do działania firmy prace, jak przyjmowanie zleceń, zaopatrzenie czy podawanie pizzy na sali lub dowóz do klienta.

Jeżeli zastanowić się nad tym modelem to można dojść do wniosku, że dokładnie takie same zasady powinno spełniać dobrze napisane oprogramowanie.
Na diagramie 2 przedstawiłem ten sam schemat pizzerii, z dodanymi nazwami jakie pojawiają się podczas projektowania oprogramowania.

Diagram 1. Pizzeria - Diagram Techniczny

Podczas takiego mapowania przyjąłem następujące założenia:

  • IoC – Szef: Zarządza pracownikami / dostarcza implementacje interfejsów,
  • IInteractor – Kucharz: Główny wykonawca zadania / Implementacja pojedynczej funkcji systemu,
  • IController – Telefon/Lada/Email: Zestaw implementacji różnych źródeł wywołań użycia funkcji programu,
  • IInteractorController – Lista zamówień: Interfejs danych wejściowych dla Interaktora, informuje jakie dane są potrzebne Interaktorowi do wykonania zadania,
  • InteractorController – Przyjmowanie zamówień: Adapter konwertujący dane pochodzące z różnych źródeł (będące w różnych formach) do formy zrozumiałej dla interaktora,
  • Dao – Hurtownia/Giełda/Mrożonki: Zestaw dostawców danych/składników przetwarzanych podczas wykonywania zadania,
  • IInteractorDao – Składzik: Interfejs , przez który dane pochodzące z różnych źródeł, są w spójny sposób dostarczane do interaktora,
  • InteractorDao – Zaopatrzenie: Adapter poszczególnych źródeł danych konwertujący je do formy odpowiedniej dla interaktora,
  • IPresenter – Dowóz/Lokal/Na wynos: Różne formy dostarczenia produktu do klienta / prezentacji wyników,
  • IInteractorPresenter – Okno podawcze: Interfejs, przez który Interaktor zwraca wyniki,
  • InteractorPresenter – Kierownik sali: Decyduje w jaki sposób dane dotrą do adresata. Adapter konwertujący wynik do formy odpowiedniej dla sposobu dostarczenia (Html, Ajax, Konsola),
  • Dependency – Piec/Przepisy: Dodatkowe komponenty potrzebne interaktorowi do wykonania zadania.

Z powyższego zestawienia wyraźnie rzuca się w oczy, że całość architektury skupia się tu dookoła Interaktora, który realizuje podstawową funkcję. Pozostałe elementy są dla niego pomocą i to one są zależne od niego, a nie odwrotnie. Interaktor “nie wie”, jakie są źródła danych, kto wywołał funkcję, a także w jaki sposób zwrócić wynik. Tak jak w pizzerii kucharz wie tylko jaką pizzę ma przygotować, gdzie ma składniki, piec i przepisy oraz gdzie ją wyłożyć gdy będzie już gotowa.

Na koniec jeszcze obiecany link: Ruby Midwest 2011 – Keynote: Architecture the Lost Years by Robert Martin

C.D.N.

Comments:0

Leave a Reply

Your email address will not be published. Required fields are marked *