Projektowanie oparte na domenie — Domain-driven design

Rozwój oprogramowania
Główne działania
Paradygmaty i modele
Metodologie i ramy
Dyscypliny wspierające
Praktyki
Narzędzia
Standardy i zbiory wiedzy
Glosariusze
Wytyczne

Domain-Driven Design ( DDD ) jest koncepcja, że struktura i język kodu oprogramowania (nazwy klas, metod klasy , zmienne klasy ) powinna być zgodna z domeny biznesu . Na przykład, jeśli oprogramowanie przetwarza wnioski o pożyczkę, może mieć klasy takie jak LoanApplication i Customer oraz metody takie jak AcceptOffer i Withdraw.

DDD łączy implementację z ewoluującym modelem.

Projekt oparty na domenie opiera się na następujących celach:

  • położenie głównego nacisku projektu na podstawową domenę i logikę domeny;
  • oparcie złożonych projektów na modelu domeny;
  • inicjowanie twórczej współpracy między ekspertami technicznymi i ekspertami dziedzinowymi w celu iteracyjnego udoskonalania modelu koncepcyjnego, który rozwiązuje konkretne problemy w danej dziedzinie.

Krytycy projektowania opartego na domenie twierdzą, że programiści muszą zazwyczaj implementować dużą ilość izolacji i hermetyzacji, aby utrzymać model jako czystą i pomocną konstrukcję. Chociaż projektowanie oparte na domenie zapewnia korzyści, takie jak łatwość konserwacji, firma Microsoft zaleca go tylko w przypadku złożonych domen, w których model zapewnia wyraźne korzyści w formułowaniu wspólnego rozumienia domeny.

Termin został ukuty przez Erica Evansa w jego książce o tym samym tytule, opublikowanej w 2003 roku.

Przegląd

Projektowanie oparte na domenie przedstawia szereg koncepcji i praktyk wysokiego poziomu.

Podstawowe znaczenie ma domena , obszarem tematycznym, do którego użytkownik stosuje program, jest domena oprogramowania. Domena oprogramowania reguluje jego kontekst , otoczenie, w którym pojawia się słowo lub stwierdzenie, które określa jego znaczenie. Na tej podstawie programiści budują model domeny : system abstrakcji, który opisuje wybrane aspekty domeny i może być wykorzystany do rozwiązywania problemów związanych z tą domeną.

Te aspekty projektowania opartego na domenie mają na celu wspieranie wszechobecnego języka, co oznacza, że ​​model domeny powinien tworzyć wspólny język używany przez ekspertów dziedzinowych do opisywania wymagań systemowych, użytkowników biznesowych, sponsorów i programistów.

W projektowaniu opartym na domenie warstwa domeny jest jedną z najczęstszych warstw w architekturze wielowarstwowej zorientowanej obiektowo .

Rodzaje modeli

Projekt oparty na domenie rozpoznaje wiele rodzajów modeli.

Na przykład jednostka jest obiektem zdefiniowanym nie przez jego atrybuty, ale jego tożsamość . Na przykład większość linii lotniczych przypisuje do miejsc w każdym locie niepowtarzalny numer: jest to identyfikator miejsca.

Natomiast obiekt wartości to niezmienny obiekt, który zawiera atrybuty, ale nie ma tożsamości pojęciowej. Na przykład, gdy ludzie wymieniają się wizytówkami, interesują się tylko informacjami na karcie (jej atrybutami), zamiast próbować rozróżniać poszczególne karty.

Modele mogą również definiować zdarzenia (co się dzieje). Wydarzenie domenowe to wydarzenie, na którym interesują się eksperci domenowi.

Modele mogą być połączone ze sobą przez jednostkę główną, aby stać się agregatem . Obiekty poza agregatem mogą posiadać referencje do korzenia, ale nie do żadnego innego obiektu agregatu. Korzeń agregatu sprawdza spójność zmian w agregacie. Kierowcy nie muszą na przykład sterować indywidualnie każdym kołem samochodu: po prostu jeżdżą samochodem. W tym kontekście samochód jest agregatem kilku innych obiektów (silnik, hamulce, reflektory itp.)

Praca z modelami

W projektowaniu opartym na domenie tworzenie obiektu jest często oddzielone od samego obiektu.

Na przykład repozytorium to obiekt z metodami pobierania obiektów domeny z magazynu danych (np. bazy danych). Podobnie fabryka to obiekt z metodami bezpośredniego tworzenia obiektów domeny.

Gdy część funkcjonalności programu nie należy koncepcyjnie do żadnego obiektu, zazwyczaj jest wyrażana jako usługa .

Związek z innymi pomysłami

Chociaż projektowanie oparte na domenie nie jest nieodłącznie związane z podejściami obiektowymi , w praktyce wykorzystuje zalety takich technik. Obejmują one jednostki/zagregowane korzenie jako odbiorniki poleceń/wywołań metod, hermetyzację stanu w ramach głównych zagregowanych korzeni oraz na wyższym poziomie architektury ograniczone konteksty.

W rezultacie projektowanie oparte na domenie jest często kojarzone z Plain Old Java Objects i Plain Old CLR Objects . Chociaż technicznie techniczne szczegóły implementacji, specyficzne odpowiednio dla Javy i .NET Framework , terminy te odzwierciedlają rosnący pogląd, że obiekty domeny powinny być definiowane wyłącznie przez zachowanie biznesowe domeny, a nie przez bardziej szczegółowe ramy technologiczne.

Podobnie wzorzec nagich obiektów utrzymuje, że interfejs użytkownika może być po prostu odzwierciedleniem wystarczająco dobrego modelu domeny. Wymaganie, aby interfejs użytkownika był bezpośrednim odzwierciedleniem modelu domeny, wymusi zaprojektowanie lepszego modelu domeny.

Projektowanie oparte na domenie wpłynęło na inne podejścia do tworzenia oprogramowania.

Na przykład modelowanie specyficzne dla domeny jest projektowaniem opartym na domenie stosowanym w językach specyficznych dla domeny . Projektowanie oparte na domenie nie wymaga używania języka specyficznego dla domeny , chociaż może być używane do definiowania języka specyficznego dla domeny i obsługi multimodelowania specyficznego dla domeny .

Z kolei programowanie aspektowe ułatwia wyodrębnienie problemów technicznych (takich jak bezpieczeństwo, zarządzanie transakcjami, logowanie) z modelu domeny, pozwalając skupić się wyłącznie na logice biznesowej.

Inżynieria i architektura oparta na modelach

Chociaż projektowanie oparte na domenie jest zgodne z inżynierią i architekturą opartą na modelach , intencja tych dwóch koncepcji jest inna. Architektura oparta na modelach jest bardziej związana z tłumaczeniem modelu na kod dla różnych platform technologicznych niż definiowaniem lepszych modeli domen.

Jednak techniki zapewniane przez inżynierię opartą na modelach (do modelowania domen, tworzenia języków specyficznych dla danej domeny w celu ułatwienia komunikacji między ekspertami dziedzinowymi a programistami...) ułatwiają praktyczne projektowanie oparte na domenie i pomagają praktykom uzyskać więcej z ich modele. Dzięki technikom transformacji modeli i generowania kodu w inżynierii opartej na modelach, model dziedzinowy może zostać wykorzystany do wygenerowania rzeczywistego systemu oprogramowania, który będzie nim zarządzał.

Segregacja odpowiedzialności za zapytania poleceń

Command Query Responsibility Segregation (CQRS) to architektoniczny wzorzec służący do oddzielania danych odczytu („zapytanie”) od zapisu do danych („polecenie”). CQRS wywodzi się z Command and Query Separation (CQS), wymyślonego przez Bertranda Meyera .

Polecenia mutują stan i są w przybliżeniu równoważne wywoływaniu metody na zagregowanych korzeniach lub jednostkach. Zapytania odczytują stan, ale go nie mutują.

Chociaż CQRS nie wymaga projektowania opartego na domenie, wyraźnie rozróżnia polecenia i zapytania za pomocą koncepcji zagregowanego katalogu głównego. Pomysł polega na tym, że dany zagregowany korzeń ma metodę, która odpowiada poleceniu, a program obsługi poleceń wywołuje metodę na zagregowanym korzeniu.

Zagregowany korzeń jest odpowiedzialny za wykonanie logiki operacji i generowanie pewnej liczby zdarzeń, odpowiedzi na awarię lub po prostu mutowanie własnego stanu, który można zapisać w magazynie danych. Program obsługi poleceń wyciąga problemy związane z infrastrukturą związane z zapisywaniem stanu zagregowanego roota i tworzeniem potrzebnych kontekstów (np. transakcji).

Pozyskiwanie zdarzeń

Pozyskiwanie źródeł zdarzeń to wzorzec architektoniczny, w którym jednostki nie śledzą swojego stanu wewnętrznego za pomocą bezpośredniej serializacji lub mapowania obiektowo-relacyjnego, ale odczytując i zatwierdzając zdarzenia w magazynie zdarzeń .

Gdy źródło zdarzeń jest połączone z CQRS i projektowaniem opartym na domenie, zagregowane katalogi główne są odpowiedzialne za weryfikację i stosowanie poleceń (często przez wywoływanie ich metod wystąpień z programu obsługi poleceń), a następnie publikowanie zdarzeń. Jest to również podstawa, na której zagregowane korzenie opierają swoją logikę dotyczącą radzenia sobie z wywołaniami metod. Dlatego dane wejściowe to polecenie, a dane wyjściowe to jedno lub wiele zdarzeń, które są zapisywane w magazynie zdarzeń, a następnie często publikowane w brokerze komunikatów dla zainteresowanych (takim jak widok aplikacji ).

Modelowanie zagregowanych korzeni do zdarzeń wyjściowych może izolować stan wewnętrzny nawet dalej niż podczas projekcji danych odczytu z jednostek, jak w standardowych n- warstwowych architekturach przekazywania danych. Jedną z istotnych korzyści jest to, że dowodzenie twierdzeń aksjomatycznych (np. Microsoft Contracts i CHESS) jest łatwiejsze do zastosowania, ponieważ zagregowany korzeń kompleksowo ukrywa swój stan wewnętrzny. Zdarzenia są często utrwalane na podstawie wersji zagregowanego wystąpienia głównego, co daje model domeny, który synchronizuje się w systemach rozproszonych za pomocą optymistycznej współbieżności .

Wybitne narzędzia

Chociaż projektowanie oparte na domenie nie zależy od żadnego konkretnego narzędzia lub struktury, godne uwagi przykłady obejmują:

  • Actifsource , wtyczka do Eclipse, która umożliwia tworzenie oprogramowania łączące DDD z inżynierią opartą na modelach i generowaniem kodu .
  • CubicWeb , platforma sieci semantycznej typu open source w całości oparta na modelu danych. Dyrektywy wysokiego poziomu pozwalają na iteracyjne udoskonalanie modelu danych, wydanie po wydaniu. Zdefiniowanie modelu danych wystarczy, aby uzyskać działającą aplikację internetową. Konieczna jest dalsza praca, aby zdefiniować sposób wyświetlania danych, gdy domyślne widoki nie są wystarczające.
  • OpenMDX , open-source, oparty na Javie, MDA Framework obsługujący Java SE , Java EE i .NET . OpenMDX różni się od typowych frameworków MDA tym, że „używa modeli do bezpośredniego sterowania zachowaniem systemów operacyjnych w czasie wykonywania” .
  • Restful Objects , standard mapowania interfejsu API Restful na model obiektów domeny (gdzie obiekty domeny mogą reprezentować jednostki, modele widoku lub usługi). Dwie platformy open source (jedna dla Javy, jedna dla .NET) mogą automatycznie tworzyć interfejs API Restful Objects z modelu domeny, korzystając z odbicia.

Zobacz też

Bibliografia

Zewnętrzne linki