Spis treści
Struktura oprogramowania
Podstawowy cel architektury to ułatwienie realizowania prac związanych z rozwojem oraz utrzymaniem oprogramowania, oraz celów postawionych przed danym oprogramowaniem.
Dobra architektura musi ułatwiać:
- Działanie systemu i wykonywanie przypadków użycia (celów postawionych przed oprogramowaniem).
- Konserwację.
- Rozwój.
- Wdrożenia.
Celem jest: minimalizacja kosztów oraz maksymalizacja produktywności. Dobre projektowanie architektury polega na przesuwaniu decyzji dotyczących szczegółów na później (gdy będziemy mieli więcej danych) i niedecydowaniu o robieniu czegoś już na początku, np. dane można zapisywać w pliku tekstowym (szczegół implementacyj ny, szybki do osiągnięcia), a nie w bazie danych. Dobra architektura pozwoli szybki podmienić szczegóły na lepsze, np. zapis danych do pliku na zapis w bazie danych.
Warto tutaj wspomnieć też o prawie Conwaya:
Organizacja projektująca system wygeneruje projekt o strukturze odwzorowującej strukturę komunikacji tej organizacji.
Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 167.
Architektura oprogramowanie rozwijanego przez wielozespołową organizację, w której zespoły realizują różne zadania, musi mieć uwzględniać aspekt struktury takiej organizacji. Architektura musi być tak stworzona, aby pozwalała różnym zespołom realizować niezależnie od innych swoje zadania.
Tworząc architekturę, należy wyznaczać granicę. System można podzielić na:
- Poziome warstwy — odpowiedzialne za konkretne działania (np.dostęp do bazy danych, interfejs użytkownika).
- Pionowe plastry — reprezentujące konkretne przypadki użycia i przecinające różne warstwy systemu.
Granice służą do oddzielenia od siebie kodu źródłowego. Pozwalają chronić komponenty przed zbyt częstymi zmianami. Zmiana powinna dotyczyć jak najmniejszej liczby komponentów. Dobre rozmieszczenie granic powinno minimalizować liczbę zmienianych komponentów. Należy stawiać granice między komponentami ważnymi (rzadko zmieniającymi się, np. reguły biznesowe), a nieważnymi (często zmieniającymi się, np. interfejs użytkownika). Stawianie granic może wyglądać następująco:
- Należy podzielić kod na komponenty (najważniejsze reguł biznesowe, interfejs użytkownika, dostęp do bazy danych, etc.).
- Przygotowanie kodu w taki sposób, aby strzałki zależności między komponentami były od mniej ważnego do ważniejszego (stosowanie Zasady Odwróconej Zależności — strzałki skierowane są od niskopoziomowych szczegółów do wysokopoziomowych abstrakcji).
Rozważmy architekturę wtyczek. Najważniejszym komponentem są reguł biznesowe. Korzystają one z interfejsu dostępu do bazy danych. Jest on zdefiniowany w komponencie z regułami biznesowymi. Implementuje go inny komponent (dostępu do konkretnej bazy danych). Zmiana bazy danych nie wpłynie na reguły biznesowe — nowy komponent dostępu do nowej bazy danych będzie musiał zaimplementować ten sam (niezmieniony) interfejs będący w komponencie z regułami biznesowymi.
Szczegółami są m.in.:
- Bazy danych.
- Sieć www.
- Frameworki.
- Interfejs użytkownika.
- Moduł Main — odpowiada za tworzenie, koordynację i nadzorowanie innych komponentów. Traktowanie go jako wtyczki i modułu ukrytego za granicą architektoniczną upraszcza znacząco konfigurowanie aplikacji.
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!