Jak rozumiem, głównym celem jest rozdzielenie logiki domeny (logiki biznesowej) od infrastruktury (DB, system plików itp.).
To jest podstawa nieporozumienia: celem DDD nie jest rozdzielanie rzeczy twardą linią, np. „To jest na serwerze SQL, więc nie może być BL”, celem DDD jest oddzielanie domen i tworzenie barier między te, które pozwalają, aby elementy wewnętrzne domeny były całkowicie oddzielone od elementów wewnętrznych innej domeny i definiowały wspólne elementy zewnętrzne między nimi.
Nie myśl o „byciu w SQL” jak o barierze BL / DL - nie o to chodzi. Zamiast tego pomyśl o „to koniec domeny wewnętrznej” jako o barierze.
Każda domena powinna mieć zewnętrzne interfejsy API, które pozwolą jej współpracować ze wszystkimi innymi domenami: w przypadku warstwy przechowywania danych powinny mieć akcje odczytu / zapisu (CRUD) dla przechowywanych obiektów danych. Oznacza to, że sam SQL nie jest tak naprawdę barierą, VIEWa PROCEDUREkomponenty są. Nigdy nie powinieneś czytać bezpośrednio z tabeli: to jest szczegół implementacji DDD mówi nam, że jako konsument zewnętrzny nie powinniśmy się martwić.
Rozważ swój przykład:
Zastanawiam się, co się dzieje, gdy mam bardzo złożone zapytania, takie jak Zapytanie dotyczące obliczania zasobów materialnych? W tego rodzaju zapytaniach pracujesz z ciężkimi operacjami ustawiania, dla których SQL został zaprojektowany.
To jest dokładnie to, co powinno być w SQL, i to nie jest naruszenie DDD. Do tego stworzyliśmy DDD . Dzięki tym obliczeniom w SQL staje się ono częścią BL / DL. Co byś zrobił, to użyć oddzielnego view / procedura przechowywana / co-ma-ty, i zachować logika biznesowa oddzielona od warstwy danych, jako że to zewnętrzny interfejs API. W rzeczywistości warstwa danych powinna być kolejną warstwą domeny DDD, w której warstwa danych ma własne abstrakty do pracy z innymi warstwami domeny.
Wykonywanie tych obliczeń w infrastrukturze również nie może się zdarzyć, ponieważ wzorzec DDD pozwala na zmiany w infrastrukturze bez zmiany warstwy domeny i wiedząc, że MongoDB nie ma takich samych możliwości jak np. SQL Server, co nie może się zdarzyć.
To kolejne nieporozumienie: mówi, że szczegóły implementacji mogą ulec zmianie bez zmiany innych warstw domeny. Nie oznacza to, że możesz po prostu wymienić cały element infrastruktury.
Ponownie, należy pamiętać, że DDD polega na ukrywaniu elementów wewnętrznych za pomocą dobrze zdefiniowanych zewnętrznych interfejsów API. To, gdzie są te interfejsy API, jest zupełnie innym pytaniem, a DDD tego nie definiuje. Określa po prostu, że te interfejsy API istnieją i nigdy nie powinny się zmieniać .
DDD nie jest skonfigurowane tak, aby umożliwić ad hoc zastępowanie MSSQL MongoDB - są to dwa zupełnie różne elementy infrastruktury.
Zamiast tego zastosujmy analogię do tego, co definiuje DDD: benzyna vs. samochody elektryczne. Oba pojazdy mają dwie zupełnie różne metody tworzenia napędu, ale mają te same API: włączanie / wyłączanie, przepustnicę / hamulec i koła do napędzania pojazdu. DDD mówi, że powinniśmy być w stanie wymienić silnik (gazowy lub elektryczny) w naszym samochodzie. Nie oznacza to, że możemy zastąpić samochód motocyklem, i tak właśnie jest MSSQL → MongoDB.