Chwilami rozmyślałem na temat projektu, jaki chciałbym zmaltretować. Wyszło przy tym kilka ciekawych pomysłów. Jednak do realizacji podejmę się projektu prostego, rozwiązującego mój mały problemik.
Gdy rękę wsadzisz w gębę Git Pulla, znikasz jak dane słane w /dev/null-a. W Programistoku wylądujesz w NET, Już nie pomoże ci CRTL+Z. Przyznam się szczerze i bez bicia od pewnego czasu jak wróciło hasło Programistok 2017...
Domain-Driven Design charakteryzuje komponenty wykorzystywane przy budowie złożonych modelów dziedziny (ang. Domain Model). Jednak owe komponenty wchodzą w skład większego bytu, posiadają swój cykl życia.
Do budowy Modelu Dziedziny (ang. Domain Model), wykorzystujemy kilka bazowych składowych powiązanych ze sobą relacjami.
Poprawne modelowanie dziedziny skutkuje bezwzględnym wymaganiem dotyczą jej izolacji od reszty systemu. Z pomocą przychodzi architektura warstwowa wyodrębniająca z aplikacji spójne ze sobą pod względem działania obszary. Zebrane w ten sposób funkcjonalności są składowymi warstw.
Odwiecznym problemem jaki napotykają na swojej drodze dwie ścierające się siły. Zlecający vs wykonawca. Wzajemna komunikacji vs zrozumienie. Problem narasta gdy obie persony obracają się w odseparowanych środowiskach.
Niniejszym otwieram cykl postów związanych z rozkminianiem architektury wytwarzania oprogramowania o nazwie DDD => Domain-Driven Design. Jest to temat jaki od pewnego czasu dręczy mnie, i chcę rozwinąć swoje zdolności w tym konkretnym obszarze.
