Domain-Driven Design - Izolacja przy pomocy warstw.

24.07.2017


Artykuł ten jest częścią serii artykułów na temat Domain-Driven Design.

Agenda

1. Wstęp.
2. Język Wszechobecny.
3. Izolacja przy pomocy warstw.
4. Podstawowe części składowe.
5. DDD i jego życie.
6. Nadejszła wiekopomna chwiła.


Wstęp

Domain-Driven Design

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. Przy czym bazowy zestaw warstw został zdefiniowany i zawiera:

  • interfejsu Użytkownika (ang. User Interface) - warstwa ta odpowiedzialna jest za kontakt ze światem zewnętrznym. Służy obsłudze funkcjonalności aplikacji przez użytkownika. Oczywiście warstwa ta może także być w formie API (Application Programming Interface). Czyli usługi udostępnionej innym aplikacjom, Np. WebSerwisy, WebSockety. Warstwa Interfejsu  Użytkownika korzysta z publicznych interfejsów upublicznionych w warstwach niższego rzędu.
  • Aplikacji (ang. Application) - jest to warstwa pośrednicząca między warstwą interfejsu, a warstwą dziedziny, wszelkie operacje deleguje do warstwy domeny, sama może posiadać stan jednak nie posiada logiki biznesowej. Jest niezbędna gdyż zarządza zadaniami jakie są zlecane z warstwy użytkownika do aplikacji. Tak jak warstwa Interfejsu Użytkownika posiada dostęp do warstw niższego rzędu. Architektura warstwowa
  • Dziedziny/Modelu (ang. Domain) - warstwa gdzie implementujemy Logikę Biznesową (ang. Bussines  Logic). Dostarcza najbardziej wartościową funkcjonalność (wartość biznesową), jest rdzeniem aplikacji. Korzysta z warstwy niżej (infrastruktury) w charakterze magazynu danych. Powinna zawierać w sobie implementację głównej funkcjonalności programu. Dzięki separacji od działań związanych ze środowiskiem w jakim uruchamiana jest aplikacja. Dużo łatwiej jest testować działanie warstwy, a także przenosić czystą formę algorytmów ustaloną z Ekspertem Domenowym (ang. Domain  Expert).
  • Infrastruktury (ang. Infrastructure) - jest to warstwa służąca do kontaktu z systemem w jakim uruchamiany jest program. Pośredniczy w korzystaniu z funkcji systemowych/usług zewnętrznych, np.:: baza danych, zapis do plików, dostęp do urządzeń zewnętrznych, zdalnych usług. Jak sama nazwa wskazuje cała infrastruktura jaka znajduje się w środowisku uruchomieniowym programu. Świadczy usługi na  rzecz warstw wyższego rzędu.

Każda z wymienionych warstw izoluje specyficzną dla siebie funkcjonalność. Pozwoliło to nie tylko odseparować Model Dziedziny (ang. Domain Model), co także uporządkować składowe elementy aplikacji.

Warstwy powinny być zależne jedynie od warstwy niższej, jednocześnie luźno powiązane z warstwami wyżej. high-cohesion

Oznacza to, iż aplikacja cechuje się: dużą spójnością (ang. high-cohesion), słabym związaniem (ang. loose-coupling).

Jakie zachodzi pomiędzy: warstwami, interfejsami, obiektami.

Zależnie od złożoności systemu, istnieje możliwość dodania kolejnych warstw w celu większego rozproszenia funkcjonalności. Należy jednak pamiętać iż, w sytuacji nadmiernego przyrostu ilości warstw rośnie także złożoność aplikacji. Ta sytuacja z kolei utrudnia utrzymanie aplikacji.

Architekturę warstwową opisywałem także w poście: Architektura cebuli.

Oczywiście nie są to wszystkie możliwe sposoby na wyizolowanie Modelu Dziedziny (ang. Domain Model)  w aplikacji…

Nadmieniam, tutaj iż głoszę swój osobisty punkt widzenia i sposób prezentacji wiedzy. A jako że nie jestem nieomylny, to mogą i zapewne będą zdarzać się błędy…

Polecane książki

Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software

Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software

Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy

Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy

Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym

Domain-Driven Design. Zapanuj nad złożonym systemem informatycznym

DDD dla architektów oprogramowania

DDD dla architektów oprogramowania

Hands-On Domain-Driven Design with .NET Core - Tackling complexity in the heart of software by putting DDD principles into practice

Hands-On Domain-Driven Design with .NET Core - Tackling complexity in the heart of software by putting DDD principles into practice

EventStorming - An act of deliberate collective learning

EventStorming - An act of deliberate collective learning

DDD: Kompendium wiedzy

DDD: Kompendium wiedzy


Wcześniejszy artykuł: Domain-Driven Design - Izolacja przy pomocy warstw.

Następny artykuł: Domain-Driven Design - Podstawowe części składowe.


Zapisz się na listę :)