Co to jest projektowanie oparte na domenie?

Czy ktoś może wyjaśnić (zwięźle), czym dokładnie jest projektowanie oparte na domenie? Często widzę ten termin, ale tak naprawdę nie rozumiem, co to jest ani jak wygląda. Czym różni się od projektowania bez domeny?

Czy ktoś może wyjaśnić, czym jest Obiekt Domeny? Czym domena różni się od zwykłych obiektów?

EDYTOWAĆ:

Ponieważ wydaje się, że jest to najlepszy wynik w Google, a moja odpowiedź poniżej nie jest, zapoznaj się z tą znacznie lepszą odpowiedzią:

https://stackoverflow.com/a/1222488/1240557

STARA ODPOWIEDŹ (nie tak kompletna :))

Aby stworzyć dobre oprogramowanie, musisz wiedzieć o co chodzi w tym oprogramowaniu. Nie możesz stworzyć systemu oprogramowania bankowego, chyba że dobrze rozumiesz, na czym polega bankowość, musisz zrozumieć dziedzinę bankowości.

Od: Projektowanie oparte na domenie autorstwa Erica Evansa.

Ta książka bardzo dobrze opisuje DDD.

Zarejestruj się, aby pobrać streszczenie książki lub pobierz je bezpośrednio .

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.

Ci MOŻE TYLKO zrozumieć Domain Driven Design przez pierwszy rozumiejąc co są następujące:

Co to jest domena?

Pole, dla którego zbudowany jest system. Zarządzanie lotniskami, sprzedaż ubezpieczeń, kawiarnie, lot orbitalny, to tylko nazwa.

Nie jest niczym niezwykłym, że aplikacja obejmuje kilka różnych domen. Na przykład internetowy system sprzedaży detalicznej może działać w obszarach wysyłki (wybierając odpowiednie sposoby dostarczania, w zależności od produktów i miejsca docelowego), cen (w tym promocji i cen specyficznych dla użytkownika według, powiedzmy, lokalizacji) i zaleceń (obliczając powiązane produkty według historii zakupów).

Co to jest model?

„Przydatne przybliżenie aktualnego problemu”. - Gerry Sussman

Klasa pracownika nie jest prawdziwym pracownikiem. Modeluje prawdziwego pracownika. Wiemy, że model nie uwzględnia wszystkiego o prawdziwych pracownikach i nie o to chodzi. Ma tylko uchwycić to, co nas interesuje w obecnym kontekście.

Różne domeny mogą być zainteresowane różnymi sposobami modelowania tego samego. Na przykład dział wynagrodzeń i dział zasobów ludzkich mogą modelować pracowników na różne sposoby.

Co to jest model domeny?

Model dla domeny.

Co to jest projektowanie oparte na domenie (DDD)?

Jest to podejście programistyczne, które głęboko ceni model domeny i łączy go z implementacją. DDD został wymyślony i początkowo opracowany przez Erica Evansa.

Wywalony stąd

Oto kolejny dobry artykuł, który możesz sprawdzić na temat projektowania opartego na domenach . jeśli twoja aplikacja jest ważniejsza niż praca w college'u. Podstawowym założeniem jest ustrukturyzowanie wszystkiego wokół swoich podmiotów i posiadanie silnego modelu domeny. Rozróżnij usługi zapewniające rzeczy związane z infrastrukturą (takie jak wysyłanie wiadomości e-mail, utrwalanie danych) i usługi, które faktycznie wykonują czynności, które są podstawowymi wymaganiami biznesowymi.

Mam nadzieję, że to pomaga.

Podobnie jak w TDD i BDD ty / zespół bardziej skupiasz się na testach i działaniu systemu niż na implementacji kodu.

Podobny sposób, w jaki analityk systemowy, właściciel produktu, zespół programistów i oczywiście kod - jednostki / klasy, zmienne, funkcje, procesy interfejsów użytkownika komunikują się w tym samym języku, zwanym projektowaniem opartym na domenie

DDD to proces myślowy. Podczas modelowania projektu oprogramowania należy utrzymywać domenę / proces biznesowy w centrum uwagi, a nie struktury danych, przepływy danych, technologie, zależności wewnętrzne i zewnętrzne.

Istnieje wiele podejść do modelowania systerm przy użyciu DDD

• pozyskiwanie zdarzeń (wykorzystanie zdarzeń jako pojedynczego źródła prawdy)
• relacyjne bazy danych
• graficzne bazy danych
• za pomocą języków funkcjonalnych

Obiekt domeny:

Mówiąc bardzo naiwnie, przedmiot, który

• ma nazwę opartą na procesie biznesowym / przepływie
• ma pełną kontrolę nad swoim stanem wewnętrznym, tj. udostępnia metody manipulowania stanem.
• zawsze przestrzegaj wszystkich niezmienników biznesowych / reguł biznesowych w kontekście ich użycia.
• przestrzega zasady pojedynczej odpowiedzialności

DDD (projektowanie oparte na domenie) jest użyteczną koncepcją do analizy wymagań projektu i radzenia sobie ze złożonością tych wymagań. Zanim ludzie analizowali te wymagania, biorąc pod uwagę relacje między klasami i tabelami, w rzeczywistości ich projektowanie opierało się na tabelach bazy danych relacje nie są stare, ale mają pewne problemy:

• W dużych projektach o złożonych wymaganiach nie jest to przydatne, chociaż jest to świetny sposób projektowania dla małych projektów.

• gdy masz do czynienia z żadnymi osobami technicznymi, które nie mają pojęcia technicznego, konflikt ten może powodować poważne problemy w naszym projekcie.

Tak więc DDD radzi sobie z pierwszym problemem z uznaniem głównego projektu za domenę i podzieleniem każdej części tego projektu na małe kawałki, które znamy z ograniczonego kontekstu i każdy z nich nie ma żadnego wpływu na inne elementy. Drugi problem został rozwiązany za pomocą wszechobecnego języka, który jest wspólnym językiem członków zespołu technicznego i właścicieli produktów, którzy nie są techniczni, ale mają wystarczającą wiedzę na temat swoich wymagań

Ogólnie rzecz biorąc, prosta definicja Domeny jest głównym projektem, który zarabia pieniądze dla właścicieli i innych zespołów.

Wierzę, że poniższy pdf da ci szerszy obraz. Projektowanie oparte na domenach autorstwa Erica Evansa

UWAGA: Pomyśl o projekcie, nad którym możesz popracować, zastosuj małe zrozumiałe rzeczy i zobacz najlepsze praktyki. Pomoże Ci to również rozwinąć umiejętność projektowania architektury mikrousług.

Nie chcę powtarzać odpowiedzi innych, dlatego krótko wyjaśniam pewne powszechne nieporozumienia

• Praktyczne zasoby: WZORY, ZASADY I PRAKTYKI PROJEKTOWANIA DOMENOWEGO autorstwa Scott Millett
• Jest to metodologia skomplikowanych systemów biznesowych. W trakcie komunikacji z ekspertami biznesowymi eliminuje wszystkie kwestie techniczne
• Zapewnia szerokie zrozumienie (uproszczonego i destylowanego modelu) biznesu w całym zespole deweloperów.
• utrzymuje model biznesowy w synchronizacji z modelem kodu za pomocą wszechobecnego języka (języka rozumianego przez cały zespół deweloperów, ekspertów biznesowych, analityków biznesowych, ...), który jest używany do komunikacji w zespole programistycznym lub programistycznym z innymi zespołami
• Nie ma to nic wspólnego z zarządzaniem projektami . Chociaż można go doskonale wykorzystać w metodach zarządzania projektami, takich jak Agile.

• Powinieneś unikać używania go w całym projekcie

  DDD podkreśla potrzebę skoncentrowania największego wysiłku na podstawowej subdomenie. Podstawowa subdomena to obszar Twojego produktu, który będzie różnicą między sukcesem a porażką. Jest to wyjątkowa zaleta produktu, ponieważ jest on budowany, a nie kupowany.

  Zasadniczo dzieje się tak, ponieważ zajmuje to zbyt dużo czasu i wysiłku. Sugeruje się więc rozbicie całej domeny na subdomenę i zastosowanie jej tylko w tych o wysokiej wartości biznesowej. (np. nie w ogólnej subdomenie, takiej jak e-mail, ...)

• To nie jest programowanie obiektowe. Jest to głównie podejście do rozwiązywania problemów i ( czasami ) nie musisz używać wzorców OO (takich jak Gang of Four) w modelach domen. Po prostu dlatego, że eksperci biznesowi nie mogą tego zrozumieć (nie wiedzą dużo o Fabryce, Dekoratorze, ...). Istnieją nawet pewne wzorce w DDD (takie jak The Transaction Script, Table Module), które nie są w 100% zgodne z koncepcjami OO.