Zasady i poziomy
Systemy informatyczne są zapisem zasad i reguł przetwarzania danych. Zasady te zgrupowane są w komponenty, komponenty są ze sobą łączone. Należy łączyć komponenty tak, aby stworzyć skierowany graf acykliczny. Wierzchołkami grafu są komponenty, a krawędziami są zależności.
Poziomy
Można zdefiniować pojęcie poziomu komponentu jako jego odległość (i zasad, które zawiera) od punktu wejścia i wyjścia danych, które ma zmieniać. Komponenty odpowiadające za wejście i wyjście danych z systemu mają poziom 0. Poziom dalszych komponentów jest coraz wyższy wraz z rosnącą odległością od wejścia lub wyjścia systemu.
Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 198 — Rysunek 19.2. — Diagram klas przedstawiający lepszą architekturę systemu.
Powyższy rysunek przedstawia program do szyfrowania. Zaproponowana struktura pozwala na oddzielenie reguł niskopoziomowych (komponent wejściowy oraz wyjściowy) od zasad wysokopoziomowych (głównego powodu istnienia aplikacji — szyfrowania). Należy tutaj podkreślić, że komponenty niższego poziomu są skierowane (zależą od) komponentów poziomu wyższego. Dzięki temu łatwo można wykorzystać reguły biznesowe w innym środowisko, np. podmieniając moduł wejścia. Nie trzeba przy tym zmieniać w ogóle modułu odpowiadającego za szyfrowanie. Komponenty niższego poziomu są jak wtyczki: można je łatwo odpiąć i wpiąć coś innego, np. zapisywanie do pliku, zapisywanie do bazy danych, czytanie na głos.
Istotne reguł biznesowe + istotne dane biznesowe = encje
Reguły biznesowe to najważniejsze zasady w organizacji. Pozwalają one zarabiać lub oszczędzać pieniądze nawet wtedy, gdy nie są zaimplementowane w żadnej aplikacji, tylko realizowane są np. manualnie przez ludzi. Są to istotne reguły biznesowe. Potrzebują one danych. Dane wykorzystywane przez istotne reguły biznesowe nazywane są istotnymi danymi biznesowymi. Połączenie istotnych reguł biznesowych (zachowań) z istotnymi danymi biznesowymi (dane) tworzą obiekty, zwane encjami.
Przypadki użycia
Przypadkiem użycia nazywane jest wykorzystanie zautomatyzowanego systemu. Określa on zasady wejścia danych, ich przetwarzania oraz wyjścia.
Przypadki użycia kontrolują encje. Encje nic nie wiedzą o przypadkach użycia. Encje mają najwyższy poziom w architekturze. To od nich wszystko zależy.
Przypadki użycia powinny operować na prostych strukturach danych (na wejściu i wyjściu). Za wszystkie poważne operacje odpowiedzialne są tylko encje.
Krzycząca architektura
Architektura systemu jest środowiskiem umożliwiającym istnienie przypadków użycia. Powinna ona już na pierwszy rzut oka informować, z jakim środowiskiem ma do czynienia programista, np. spojrzenie na architekturę sklepu internetowego powinno od razu informować programistę, że ma do czynienia ze sklepem internetowym. Architektura powinna od razu krzyczeć o tym, jaką aplikację reprezentuje. Pamiętajmy, że frameworki, bazy danych, interfejs użytkownika są tylko szczegółami. Najważniejsze są przypadki użycia. To je powinien zobaczyć programista od razu, kiedy spojrzy na strukturę aplikacji. Skupienie się na przypadkach użycia, a nie na frameworkach, pozwala na bezpieczny rozwój aplikacji przez dziesięciolecia, bez uzależniania się od frameworków, narzędzi i środowisk.
Wszystkie posty związane z mini projektem: Budowa czystej architektury:
- Początek mini projektu: Budowa czystej architektury
- Architektura
- Paradygmaty programowania
- Zasady SOLID w kontekście architektury
- Spójność komponentów
- Łączenie komponentów
- Struktura oprogramowania
- Zasady i poziomy
- Czysta architektura
- Budowanie Czystej architektury
- Podsumowanie projektu: Budowanie czystej architektury
- Moje notatki z nauki szybkiego czytania
Źródła
Obrazy
Materiały
- Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.
Subskrybuj!