DDD: jak powinny być zorganizowane warstwy?

Question

DDD: jak powinny być zorganizowane warstwy?

Jestem bardzo nowy w tworzeniu oprogramowania. Osobiście uważam, że architektura warstwowa jest świetnym sposobem na zmniejszenie złożoności pojawiających się w procesie tworzenia oprogramowania w podejściu obiektowym i, nie wspominając, aby utrzymać porządek w kodzie. Teraz napotkałem pewne problemy, które należy wprowadzić z DDD (Domain Driven Design). Oczywiście, poziom początkujący.
Tutaj jest -
Powiedzmy, że chcę zbudować aplikację, która zapisuje dane związane z" osobą " w bazie danych i wyświetla szczegóły osoby w datagrid WPF (DDD na pewno nie jest dla aplikacji o takiej skali, ale po prostu, aby zachować rzeczy proste dla amatora jak ja). Tak więc, zaprojektowałem klasę domenową "Person", coś w stylu –

public class Person
 {
    public Person(dataType paramA, dataType paramB)
    {
        _fieldA = paramA;
        _fieldB = paramB;
    }

    private dataType _fieldA;
    public dataType PropertyA
    {
        //encapsulates _fieldA    
    }

    private dataType _fieldB;
    public dataType PropertyB
    {        
        //encapsulates _fieldB    
    }

    public dataType PropertyX
    {        
        //some code based on private fields    
    }

    public dataType PropertyY
    {        
        //some code based on private fields    
    }

    private dataType MethodPQR(dataType param)
    {        
        //some code    
    }

    public dataType MethodUVW(dataType paramOne, dataType paramTwo)
    {        
        //some code    
    }
}

Teraz, moje zrozumienie DDD mówi Architektura (najprostsza wersja) powinna być następująca (proszę, popraw mnie, jeśli się mylę) –
Tutaj wpisz opis obrazka
Uwaga:

Chcę, aby datagrid był związany z jakąś Obserwowalną kolekcją, aby odzwierciedlić wszelkie zmiany natychmiast.
Jest to aplikacja wpf, ale niekoniecznie musi być we wzorcu MVVM i celowo chcę użyć kodu za (nie mam pojęcia, czy kod za sobą reprezentuje warstwę aplikacji)

Więc moje pytania to –

Jakie kody powinny należeć do warstwy aplikacji?
Domyślam się, że zdecydowanie nie powinienem wiązać obserwowalnego elementu domeny (osoby) jako źródła itmsSource z datagrid. Jaki typ obiektu powinienem wyodrębnić z obiektu domain i w jaki sposób?
Aby zachować odsprzęganie obiektów warstwy prezentacji betwen I obiektu warstwy domeny może być tam jest konwencja jak “never instantiate domain objects directly in presentation layer”. Jakie są więc podejścia nie - "bezpośrednie"?
Jeśli kod-Behind rozmawia z warstwą aplikacji, to czy warstwa aplikacji powinna rozmawiać z repozytorium? Ale co, jeśli potrzebny jest jakiś dostęp do domeny, który jest związany z dostępem do danych , a nie (może nie być w tej aplikacji, ale może się zdarzyć, prawda?) Kim jest ten X w warstwie domeny, z którym powinna rozmawiać warstwa aplikacji?

Wiem, że wszystkie moje pytania i problemy są na bardzo amatorskim poziomie. Ale są to pytania i problemy. Tak więc, jeśli ktoś ma czas, każda odpowiedź zostanie doceniona.

EDIT: Nie jestem pewien, czy repozytorium danych powinno mieć odniesienie do modelu domeny.

31

repository code-organization domain-driven-design layer project-organization

Author: atiyar, 2011-05-04

Source

1 answers

score 35 · Accepted Answer

Mówiąc o bardziej "klasycznym" DDD, obiekty domeny yes zazwyczaj nie są dozwolone nigdzie poza domeną. Nie jest jednak bezwzględną regułą, że obiekty domeny nie są używane w warstwie prezentacji. Na przykład Naked Objects reprezentuje szkołę myślenia, w której obiekty domeny są używane bezpośrednio. Sam wyznaję głównie filozofię, w której przedmioty domeny nie są używane bezpośrednio, więc nie jestem zaznajomiony ze wszystkimi praktykami, które sugerują, osobiście uważam, że wiązanie z obiekt domeny bezpośrednio byłby źle poinformowany, ale ... Po prostu należy pamiętać, że nie wszyscy postrzegają to jako wymóg.

Jeśli nie zezwalasz na obiekty domeny poza samą domeną, zazwyczaj używasz Dto lub obiektów transferu danych, które są zwykłymi klasami właściwości, które nie mają zachowań domeny. Dto często dokładnie odzwierciedla strukturę modelu domeny, ale nie musi.

Logika biznesowa ma być zaimplementowana w modelu domeny, tak wiele z tego, co jest w warstwa aplikacji zajmuje się koordynowaniem różnych usług, zazwyczaj w celu dostarczenia danych do i z aplikacji klienckich. Wiele osób korzysta w tym celu z jakiejś formy SOA lub przynajmniej usług internetowych. Wywołują one repozytoria, ale wymagają również innych komponentów, takich jak assemblery, aby pobierały obiekty domeny zwracane z wywołań repozytorium i kopiowały wartości właściwości do DTOs, które następnie są serializowalne i zwracane do wywołującego. Rozmówca jest często prezenterem lub kontrolerem, ale jeśli nie są używane MVC lub MVP wywołujący nadal będzie w warstwie prezentacji. Odwrotna podróż jest bardziej złożona - interfejs może wysyłać DTOs, które reprezentują aktualizacje lub DTOs, które reprezentują nowe obiekty do dodania. Pośredniczenie w tych działaniach jest przede wszystkim celem warstwy aplikacji.

Jeśli chodzi o "nie-dostęp do danych" warstwy domeny, istnieje kilka typowych przykładów. Większość ludzi zazwyczaj odnosi się do komponentu" X", o którym możesz myśleć jako o usłudze domenowej. Usługa domeny różni się od usługi aplikacji bliskością modelu domeny i obecnością rzeczywistej logiki biznesowej.

Na przykład, jeśli aplikacja wiąże się z jakimś złożeniem zamówienia, istnieją w rzeczywistości dwie kwestie-złożenie zamówienia i realizacja zamówienia. Usługi aplikacyjne pośredniczą w przekazywaniu danych potrzebnych do sformułowania zamówienia do interfejsu użytkownika, a następnie zwracają zamówienie, które użytkownik chce złożyć. Ale to tylko mediacja transferu danych i tam kończą się usługi aplikacji. Usługa domeny może być następnie potrzebna do zastosowania reguł biznesowych i konstruowania dodatkowych obiektów domeny, które są potrzebne do faktycznego spełnienia tego zamówienia.

Ogólnie uważam, że jest to użyteczna koncepcja lub metafora, która może być zastosowana do wielu scenariuszy - usługa aplikacji ułatwia pewnego rodzaju żądanie, tylko pod względem żądania submission . Usługa domeny z drugiej strony ułatwia rzeczywiste żądanie .

Jedynym sposobem "dostępu" innym niż zorientowane na dane, z jakim się spotkałem lub mogę sobie łatwo wyobrazić, jest funkcjonalność zorientowana na proces. Nie jest to spotykane w każdej aplikacji, ale jest powszechne w niektórych dziedzinach. Na przykład w opiece zdrowotnej, w której pracuję, możesz potrzebować aplikacji, które zawierają istotne elementy zarządzania zarówno danymi klinicznymi, jak i procesem klinicznym. Rozwiązuję ten problem nie czyniąc tego procesu częścią mojego model domeny i używanie do tego różnych narzędzi.

Techniki OOP nie są dobrze dostosowane do rzeczywistego procesu, są one przydatne do dostarczania danych i przechwytywania danych z procesu. Object oriented to w końcu przede wszystkim rzeczownik oriented. Do zarządzania procesami w czasie rzeczywistym potrzebujesz "programowania zorientowanego na czasowniki "bardziej niż"programowania zorientowanego na rzeczowniki". Narzędzia Workflow to narzędzia "zorientowane na czasowniki", które mogą być komplementarne do modeli opartych na domenie dla aplikacji, które są zarówno dane intensywne, jak i procesy intensywne. Wykonuję dużo pracy, która obejmuje zarówno modele C# DDD, jak i modele Workflow Foundation, ale znowu jest to potrzebne tylko dla niektórych typów aplikacji. Wiele typowych aplikacji biznesowych wymaga tylko Modeli domen i usług.

W końcu najważniejszym aspektem DDD nie jest żadna technika czy architektura. Jego prawdziwe serce obraca się wokół wszechobecnego języka i interakcji z (moim zdaniem bezpośrednia interakcja z) specjaliści od domen, aby wydobyć krytyczną wiedzę na temat domen. (Większość firm, które twierdzą, że DDD moim zdaniem nie, ponieważ tak wiele firm odmawia zgody na bezpośrednią interakcję z biznesem i rozwojem, ale to inny temat... ) Jest to ekstrakcja i włączenie wiedzy z dziedziny, a nie jakakolwiek technika, która faktycznie oddziela DDD od konwencjonalnego OOP i tam powstaje prawdziwa wartość DDD.

EDIT

Jeśli chodzi o wykorzystanie repozytorium, schemat jest poprawny. Zazwyczaj warstwa aplikacji zawsze przechodzi przez repozytorium obiektów domeny. Przede wszystkim musisz być w stanie dostarczyć dane do aplikacji, a większość aplikacji również potrzebuje pewnego poziomu zdolności zapytań.

Warstwa domen OTOH zwykle nie wchodzi w interakcję z repozytoriami. Zazwyczaj chcesz, aby model domeny był niezależny i oddzielony od konkretnej technologii, tj. powinien reprezentować "czystą wiedzę o domenie". Trwałość jest z natury ściśle powiązane z jakąś konkretną technologią, więc ogólnie ludzie starają się uczynić swoje modele domen wolnymi od jakiejkolwiek implementacji trwałości. Masz repozytoria, ale zazwyczaj nie chcesz wywoływać metod repozytoriów w modelu domeny.

Wewnątrz samego modelu domeny obiekty są uzyskiwane jako nowe obiekty (które mogą być tworzone bezpośrednio lub przez fabrykę) lub uzyskiwane przez przechodzenie skojarzeń. Czasami przy tworzeniu nowego obiektu jest niepraktyczne jest przekazywanie wszystkiego do konstruktora, więc jest to jeden przypadek, w którym możesz potrzebować pewnego rodzaju dostępu do danych w samym modelu domeny. Zazwyczaj to, co ludzie robią, to przekazywanie danych za pośrednictwem interfejsu, dzięki czemu model domeny może być wyposażony w dostęp do danych, ale pozostaje oddzielony od implementacji warstwy danych. Ale w przeważającej części Obiekty domeny działają i współdziałają z innymi obiektami domeny, które są już utworzone.