Zasady i poziomy

przez | 1 czerwca, 2020

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.

Bestseller dnia w księgarni Złote Myśli

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:

Źródła

Obrazy

Materiały

  • Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *