Domain Driven Design jest metodologią i zaleceniami dotyczącymi procesu opracowywania złożonych systemów, których celem jest mapowanie działań, zadań, zdarzeń i danych w dziedzinie problemowej na artefakty technologiczne domeny rozwiązania.
Nacisk na projektowanie oparte na domenie polega na zrozumieniu problematycznej domeny w celu stworzenia abstrakcyjnego modelu domeny problemowej, który następnie można wdrożyć w określonym zestawie technologii. Projektowanie oparte na domenie jako metodologia dostarcza wskazówek, w jaki sposób rozwój tego modelu i rozwój technologii może doprowadzić do tego, że system spełni potrzeby osób korzystających z niego, a jednocześnie będzie odporny na zmiany w dziedzinie problematycznej.
Strona procesowa Domain Driven Design obejmuje współpracę między ekspertami domeny, osobami znającymi domenę problemową, a ekspertami od projektowania / architektury, osobami znającymi domenę rozwiązania. Chodzi o to, aby mieć wspólny model ze wspólnym językiem, aby ludzie z tych dwóch różnych domen z ich dwóch różnych perspektyw omawiali rozwiązanie, tak naprawdę dyskutują o wspólnej bazie wiedzy przy użyciu wspólnych koncepcji.
Brak wspólnego zrozumienia domeny problemowej między osobami potrzebującymi konkretnego systemu a osobami projektującymi i wdrażającymi system wydaje się być główną przeszkodą dla udanych projektów. Domain Driven Design to metodologia pozwalająca rozwiązać tę przeszkodę.
To coś więcej niż posiadanie modelu obiektowego. Nacisk kładziony jest na wspólną komunikację i poprawę współpracy, dzięki czemu można odkryć rzeczywiste potrzeby w obrębie problematycznej domeny i stworzyć odpowiednie rozwiązanie spełniające te potrzeby.
Projektowanie oparte na domenie: dobre i wymagające stanowi krótki przegląd tego komentarza:
DDD pomaga odkryć architekturę najwyższego poziomu i informuje o mechanice i dynamice domeny, którą oprogramowanie musi replikować. Konkretnie oznacza to, że dobrze przeprowadzona analiza DDD minimalizuje nieporozumienia między ekspertami domeny a architektami oprogramowania, a także zmniejsza późniejszą liczbę kosztownych wniosków o zmianę. Dzieląc złożoność domen na mniejsze konteksty, DDD unika zmuszania architektów projektu do projektowania rozdętego modelu obiektowego, w którym traci się dużo czasu na wypracowanie szczegółów implementacyjnych - częściowo dlatego, że liczba podmiotów, z którymi trzeba się zmierzyć, często rośnie poza wielkość białych tablic do sali konferencyjnej.
Zobacz także ten artykuł Projektowanie oparte na domenie dla architektury usług, który stanowi krótki przykład. Artykuł zawiera następujący miniaturowy opis projektu opartego na domenie.
Domain Driven Design zaleca modelowanie w oparciu o rzeczywistość biznesową, stosownie do naszych przypadków użycia. W miarę starzenia się i obniżania poziomu szumu wielu z nas zapomina, że podejście DDD naprawdę pomaga w zrozumieniu problemu i projektowaniu oprogramowania w kierunku powszechnego zrozumienia rozwiązania. Podczas tworzenia aplikacji DDD mówi o problemach jako domenach i poddomenach. Opisuje niezależne kroki / obszary problemów jako ograniczone konteksty, podkreśla wspólny język mówienia o tych problemach i dodaje wiele technicznych pojęć, takich jak byty, obiekty wartości i agregowane reguły root, aby wesprzeć wdrożenie.
Martin Fowler napisał szereg artykułów, w których wspomniano o metodologii Domain Driven Design. Na przykład ten artykuł, BoundedContext , zawiera omówienie ograniczonej koncepcji kontekstu opracowanej przez Domain Driven Development.
W tych młodszych czasach doradzono nam zbudowanie ujednoliconego modelu całej firmy, ale DDD uznaje, że nauczyliśmy się, iż „całkowite ujednolicenie modelu domeny dla dużego systemu nie będzie wykonalne ani opłacalne” 1 . Zamiast tego DDD dzieli duży system na powiązane konteksty, z których każdy może mieć zunifikowany model - zasadniczo sposób na zbudowanie MultipleCanonicalModels.