Hej, właśnie skończyłem mój mini projekt: Budowanie czystej architektury. Uczyłem się podczas niego zasad tworzenia dobrego oprogramowania. Zebrałem wszystkie moje notatki w jedno miejsce. Możesz je otrzymać zapisując się na mój newsletter 🙂 Wszystkie posty związane z mini projektem: Budowa czystej architektury: Źródła Obraz główny https://www.pexels.com/photo/person-holding-black-pen-1109541/
Podsumowanie projektu: Budowanie czystej architektury Dzisiaj zakończyłem mini projekt. Pora zatem na podsumowanie i trochę przemyśleń. Cel projektu Przerobiłem książkę Czysta Architektura Roberta C. Martina, zrobiłem notatki oraz obejrzałem trochę wykładów o tej architekturze. W najbliższym czasie wykorzystam tę wiedzę w praktyce (w pracy zawodowej). Projekt trochę rozjechał się w czasie — był wymagający intelektualnie oraz przekładanie go na wieczór też nie jest dobrym pomysłem. Trójkąt projektu Projekt składa się… Dowiedz się więcej »
Budowanie Czystej architektury Architekturę można budować oraz rozwijać w następujący sposób: Zdefiniuj wszystkich aktorów systemu oraz przypadków użycia (zgodnie z Zasadą Pojedynczej Odpowiedzialności aktor jest głównym źródłem zmiany) Rozdziel system ze względu na aktorów oraz zmiany, które mogą powodować. Podziel go tak, aby zmiany wprowadzane ze względu na jednego aktora, nie wpływały na innego aktora. Połącz komponenty na podstawie zasady zależności: zależności muszą być skierowane w stronę komponentów o wyższym… Dowiedz się więcej »
Czysta architektura Czysta architektura jest bardzo podobna do innych architektur: Architektury Heksagonalnej, Architektury Portów i Adapterów, DCI (opracowanej przez Jamesa Colliena i Trygve’a Reenskaug’a) oraz BCE (opracowaną przez Ivara Jacobsena). Powyższe architektury mają ten sam cel. Jest nim oddzielenie od siebie różnych zadań. Osiągają to w ten sam sposób: dzielą oprogramowanie na warstwy i wyróżniają: warstwę biznesową, interfejs użytkownika i interfejs systemowy. Różnią się ona między sobą tylko szczegółami. Wszystkie… Dowiedz się więcej »
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… Dowiedz się więcej »
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,… Dowiedz się więcej »
Łączenie komponentów Tworząc architekturę, należy zastanowić się, w jaki sposób połączyć ze sobą komponenty. Pomocne są w tym następujące zasady: Zasada zależności niecyklicznych. Zasada stabilnych zależności. Zasada stabilnych abstrakcji. Zasada zależności niecyklicznych Nie dopuść do powstania cyklicznych związków w diagramie zależności komponentów. Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 132. Zmniejsza to zależność jednych komponentów od drugich — sprawia,… Dowiedz się więcej »
Komponenty Komponenty to najmniejsze wdrożeniowe elementy oprogramowania, które można instalować. Spójność komponentów Spójność komponentów oznacza składanie komponentów takich sposób, aby zachowywały one harmonię oraz były jak najbardziej jednolite. W zapewnianiu spójności komponentów pomagają następujące zasady: REP — Zasada istotności numeru wydania (ang. Reuse/Release Equivalence Principle). CCP — Zasada wspólnego domknięcia (ang. Common Closure Principle). CRP — Zasada wspólnego użycia (ang. Common… Dowiedz się więcej »
Zasady SOLID Dobre oprogramowanie na najniższym poziomie powinno być zgodne z zasadami SOLID. Znajomość tych zasad przyda się również przy projektowaniu całej architektury. Można je bowiem rozszerzyć na komponenty, moduły i paczki. Poniżej przedstawiam zasady SOLID. SRP — Zasada pojedynczej odpowiedzialności – (ang. Single Responsibility Principle) Każdy moduł powinien odpowiadać dokładnie przed jednym aktorem (mieć dokładnie jedną zmian). Należy oddzielać od siebie fragmenty… Dowiedz się więcej »
Paradygmaty programowania Paradygmat to zbiór pojęć i teorii, które tworzą daną dyscyplinę. W programowaniu są trzy paradygmaty: programowanie strukturalne, programowanie obiektowe i programowanie funkcyjne. Żaden z nich nie mówi, jak należy programować. Wręcz odwrotnie, każdy z nich ogranicza wolność w programowaniu. Wygląda to następująco (źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin, ss. 46-47): Programowanie strukturalne wymusza dyscyplinę bezpośredniego przekazywania sterowania… Dowiedz się więcej »
Architektura Architektura oprogramowania to połączenie wysokopoziomowej struktury z niskopoziomowymi szczegółami, relacje między nimi, reguły ich rozbudowywania oraz środowisko pracy. Jej celem jest zminimalizowanie liczby ludzi wymaganych do stworzenia, utrzymywania i rozbudowywania systemu. Zasady programowania nie zmieniły się od swoich początków. Ciągle używane są te same komendy (np. if’y i while). Są one uniwersalne. Z tego też powodu reguły architektury oprogramowania są uniwersalne i nie zależą od żadnej zmiennej. Dobra architektura ma następujące zalety:… Dowiedz się więcej »
Cele i ramy czasowe Rozpoczynam dziś kolejny mini projekt. Codziennie (oprócz niektórych niedziel) przez najbliższy miesiąc będę poświęcał na ten projekt 1 godzinę. Jego celem jest dokształcenie się z obszaru tworzenia dobrej architektury oprogramowania na podstawie koncepcji Czystej Architektury, zwanej inaczej architekturą cebulkową (Onion Architecture) lub Posty i Adaptery. Dlaczego 1 miesiąc? Dlaczego 1 godzina dziennie? Słyszałem, że wystarczy przez 3 miesiące poświęcać danej… Dowiedz się więcej »