Czy projektowanie oparte na domenie jest wzorcem anty-SQL?

44

Nurkuję w projektowaniu opartym na domenie (DDD) i chociaż zagłębiam się w to, jest kilka rzeczy, których nie rozumiem. Jak rozumiem, głównym celem jest rozdzielenie logiki domeny (logiki biznesowej) od infrastruktury (DB, system plików itp.).

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. Wykonywanie tych obliczeń w warstwie domeny i praca z wieloma zestawami jest jak wyrzucenie technologii SQL.

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ć.

Czy to pułapka na wzór DDD?

Leonardo Mangano
źródło
34
Chociaż SQL został zaprojektowany do obsługi algebry zestawów relacyjnych, nie jest to zabawny dzień, gdy zdasz sobie sprawę, że połowa logiki biznesowej jest pochowana w garstce funkcji SQL, które są trudne do refaktoryzacji, a jeszcze trudniejsze do przetestowania. Przeniesienie tego do warstwy domeny, w której może grać z przyjaciółmi, wydaje mi się atrakcyjne. Czy to wyrzuca sporą część technologii SQL? Jasne, ale SQL jest o wiele łatwiejszy do zarządzania, gdy używasz tylko SELECT / JOIN.
Jared Goguen
30
@JaredGoguen, ale może to być spowodowane tym, że nie jesteś ekspertem SQL, a nie technologią
Leonardo Mangano
2
@JimmyJames starałem się powiedzieć, że jeśli DDD jest dobrze zaimplementowane, pozwala zmieniać warstwy przy minimalnym wysiłku, np. Przejście z SQL Server na MongoDB. Ale jeśli masz złożone zapytania w SQL, możliwe, że nie będę mógł przejść do MongoDB, ponieważ mają one różnice techniczne. Myślę, że powiedziałem oczywistą rzecz.
Leonardo Mangano
7
... is like throwing away the SQL technologyTo, że dana technologia może coś zrobić, nie oznacza, że ​​jest to najlepszy wybór. To niepotwierdzone dowody, ale spotkałem o wiele za dużo firm, które przechowywały logikę biznesową w bazie danych i migrują z niej z powodu długotrwałych problemów związanych z utrzymaniem. Uproszczenie, ale bazy danych służą do przechowywania danych, a języki programowania służą do przekształcania danych. Nie chciałbym używać bazy danych do logiki biznesowej, niż chciałbym użyć mojej aplikacji do bezpośredniego przechowywania danych.
Conor Mancone
8
Sam SQL jest doskonałym przykładem DDD. W obliczu organizowania powiązanych danych ludzie najpierw określili do tego język: SQL. Wdrożenie nie ma większego znaczenia. Administrator bazy danych nie musi znać C / C ++, aby wykonać zapytanie do bazy danych. Podobnie w obliczu zadania planowania zdarzeń ktoś wymyślił składnię CRON (mhdmw) prosty model domeny, który pasuje do 99% problemów z planowaniem. Rdzeniem DDD nie jest tworzenie klas ani tabel itp. Chodzi o zrozumienie problemu i wymyślenie systemu do pracy w domenie problemowej
slebetman

Odpowiedzi:

39

Obecnie prawdopodobnie odczyty (zapytania) będą obsługiwane inaczej niż zapisy (polecenia). W systemie ze skomplikowanym zapytaniem jest mało prawdopodobne, aby samo zapytanie przeszło przez model domeny (który jest przede wszystkim odpowiedzialny za utrzymanie spójności zapisów ).

Masz absolutną rację, że powinniśmy renderować w SQL to, co jest SQL. Dlatego zaprojektujemy model danych zoptymalizowany wokół odczytów, a zapytanie tego modelu danych zwykle będzie zawierało ścieżkę kodu, która nie obejmuje modelu domeny (z możliwym wyjątkiem pewnej weryfikacji danych wejściowych - zapewniając parametry w zapytaniu są rozsądne).

VoiceOfUnreason
źródło
13
+1 Dobra odpowiedź, ale powinieneś nadać tej koncepcji jej właściwą nazwę, Segregacja Dowodzenia-Pytań.
Mike
6
@ Mike Posiadanie zupełnie różnych modeli do czytania i pisania bardziej przypomina CQRS niż CQS.
Andy
3
„Model odczytu” nie jest modelem domeny (lub jego częścią)? Nie jestem ekspertem od CQRS, ale zawsze myślałem, że model poleceń jest zupełnie inny niż klasyczny model domeny, ale nie model odczytu. Więc może możesz podać przykład?
Doc Brown
Zbyt długo zajęło mi uświadomienie sobie, że Znak High Performance zwraca uwagę na literówkę.
VoiceOfUnreason
@DocBrown - oto moja próba wyjaśnienia -> cascadefaliure.vocumsineratio.com/2019/04/…
VoiceOfUnreason
21

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.

410_Gon
źródło
1
Dziękuję za wyjaśnienie. Dla mnie to bardzo trudny temat, każdy ma inny punkt widzenia. Jedyne, z czym się nie zgadzam, to porównanie MSSQL (samochód) i MongoDB (motocykl), dla mnie właściwym porównaniem jest to, że są to dwa różne silniki dla tego samego samochodu, ale to tylko opinia.
Leonardo Mangano
8
@LeonardoMangano Ah, ale nie są. MSSQL to relacyjna baza danych, MongoDB to baza danych dokumentów. Tak, „baza danych” opisuje oba, ale to tyle, ile się da. Techniki odczytu / zapisu są zupełnie inne. Zamiast MongoDB możesz użyć Postgre lub MySQL jako alternatywy, a to byłoby prawidłowe porównanie.
410_Gon
3
„Nigdy nie powinieneś czytać bezpośrednio ze stołu ...” Szaleństwo.
jpmc26
„Nigdy nie powinieneś czytać bezpośrednio ze stołu ...” Jest to zasada, którą wdrożyłem samodzielnie po dekadzie pisania oprogramowania, które łączy się z bazami danych i cierpi z powodu wczesnego bólu związanego z próbą wykonania samouczków zorganizowanych wokół popularne wzory.
Lucyfer Sam
@LuciferSam Aye. Znacznie ułatwia zarządzanie separacją między szczegółami implementacji a granicami domen. Jeden „obiekt” w domenie może być reprezentowany przez 5 tabel, więc używamy widoku do enkapsulacji tego obiektu.
410_Gone
18

Jeśli kiedykolwiek brałeś udział w projekcie, w którym organizacja płacąca za hostowanie aplikacji uzna, że ​​licencje warstwy bazy danych są zbyt drogie, docenisz łatwość migracji bazy danych / magazynu. Biorąc wszystko pod uwagę, chociaż tak się dzieje, nie zdarza się to często .

Możesz powiedzieć, co najlepsze z obu światów. Jeśli rozważasz wykonywanie złożonych funkcji w bazie danych jako optymalizację, możesz użyć interfejsu, aby wprowadzić alternatywną implementację obliczeń. Problem polega na tym, że musisz utrzymywać logikę w wielu lokalizacjach.

Odbiegając od wzoru architektonicznego

Jeśli znajdziesz się w sprzeczności z implementacją wzorca lub odejściem w jakimś obszarze, musisz podjąć decyzję. Wzór to po prostu szablonowy sposób robienia rzeczy, które pomagają zorganizować projekt. W tym momencie poświęć czas na ocenę:

  • Czy to właściwy wzór? (wiele razy tak jest, ale czasami jest to po prostu złe dopasowanie)
  • Czy powinienem odstąpić w ten jeden sposób?
  • Jak daleko do tej pory się zboczyłem?

Przekonasz się, że niektóre wzory architektoniczne dobrze pasują do 80-90% twojej aplikacji, ale nie tak bardzo do pozostałych bitów. Sporadyczne odstępstwa od zalecanego wzoru są przydatne ze względów wydajnościowych lub logistycznych.

Jeśli jednak okaże się, że skumulowane odchylenia stanowią ponad 20% architektury aplikacji, prawdopodobnie jest to po prostu złe dopasowanie.

Jeśli zdecydujesz się kontynuować architekturę, zrób sobie przysługę i udokumentuj, gdzie i dlaczego odstąpiłeś od zalecanego sposobu robienia rzeczy. Gdy zyskasz nowego entuzjastycznego członka swojego zespołu, możesz wskazać mu tę dokumentację, która zawiera pomiary wydajności i uzasadnienia. Zmniejszy to prawdopodobieństwo powtarzania próśb o naprawienie „problemu”. Ta dokumentacja pomoże również zniechęcić do szalejących odchyleń.

Berin Loritsch
źródło
Unikałbym używania w odpowiedziach zwrotów typu „czy to właściwy wzór”. Wystarczająco trudno jest nakłonić ludzi do sprecyzowania, kiedy piszą swoje pytania, a według własnego uznania „czasami jest to kiepskie dopasowanie”, co sugeruje, że nie, to nie jest właściwy schemat.
Robert Harvey
@RobertHarvey, byłem w projektach, w których zastosowany wzorzec był po prostu nieodpowiedni dla aplikacji, co spowodowało, że zawiodło ono w niektórych pomiarach jakości. Z pewnością nie jest to normą, ale kiedy tak się dzieje, masz trudną decyzję o zmianie architektury lub o utrzymaniu kodu w aplikacji. Im szybciej będzie można określić złe dopasowanie, tym łatwiej będzie to naprawić. Dlatego zawsze uwzględniam tę myśl podczas oceny przypadków skrajnych. Wraz z ostatnim pociskiem czasami nie zdajesz sobie sprawy, jak źle to pasuje, dopóki nie zobaczysz nagromadzenia odchyleń.
Berin Loritsch
7

Ustawioną logikę manipulacji, w której dobrze posługuje się SQL, można bez problemu zintegrować z DDD.

Powiedzmy na przykład, że muszę znać jakąś wartość zagregowaną, całkowitą liczbę produktów według rodzaju. Łatwy do uruchomienia w sql, ale powolny, jeśli załaduję każdy produkt do pamięci i dodam je wszystkie.

Po prostu wprowadzam nowy obiekt Domain,

ProductInventory
{
    ProductType
    TotalCount
    DateTimeTaken
}

i metodę w moim repozytorium

ProductRepository
{
    List<ProductInventory> TakeInventory(DateTime asOfDate) {...}
}

Jasne, może teraz polegam na tym, że moja DB ma pewne umiejętności. Ale nadal technicznie mam separację i dopóki logika jest prosta, mogę argumentować, że nie jest to „logika biznesowa”

Ewan
źródło
Do tej pory pamiętam. Repozytoria powinny również uzyskać Queryjako parametry. repository.find(query);. Przeczytałem to samo, ale z Specs. That opens a door to leave Query` jako abstrakcją i / QueryImpllub implementacją konkretnego zapytania do warstwy infrastruktury.
Laiv
5
o Boże, wiem, że niektórzy to robią, ale myślę, że to okropne. Możesz postrzegać tego rodzaju rzeczy jako krok w dół tej drogi. Ale myślę, że można to zachować ostrożność.
Ewan
I know some people do thatniektórzy ludzie są kluczowi i jego ramy. SpringFramework ma wiele tego :-). W każdym razie, jak sugeruje @VoiceOfUnreason, kluczem do DDD jest zachowanie spójności pism. Nie jestem pewien, czy wymuszam projektowanie za pomocą modeli domen, których jedynym celem jest zapytanie lub parametryzacja zapytań. Można to rozwiązać poza domeną za pomocą struktur danych (pocos, pojos, dtos, maperów wierszy, cokolwiek).
Laiv
oczywiście potrzebujemy jakiegoś rodzaju inkwizycji, aby pomóc tym ludziom wrócić do zdrowia psychicznego. Ale trzymam się broni. Częściowe ujawnienie warstwy danych jest dopuszczalne, gdy obiektywnie zapewnia lepszą aplikację, gdzie to, co jest lub nie jest „obiektem domeny”, jest subiektywne
Ewan
1
@LeonardoMangano zależy od Twojej aplikacji i wdrożenia. Najważniejszą rzeczą do zrealizowania jest to, że możesz ponownie zinterpretować swoją domenę, aby było to możliwe.
Ewan
3

Jednym z możliwych sposobów rozwiązania tego dylematu jest myślenie o SQL jako o asemblerze: rzadko, jeśli w ogóle, kodujesz bezpośrednio w nim, ale tam, gdzie liczy się wydajność, musisz być w stanie zrozumieć kod wygenerowany przez C / C ++ / Golang / Rust kompilator, a może nawet napisać mały fragment kodu w asemblerze, jeśli nie możesz zmienić kodu w swoim języku wysokiego poziomu, aby wygenerować pożądany kod maszynowy.

Podobnie w dziedzinie baz danych i SQL różne biblioteki SQL (niektóre z nich to ORM ), np. SQLAlchemy i Django ORM dla Python, LINQ dla .NET, zapewniają abstrakcje wyższego poziomu, ale w miarę możliwości używają wygenerowanego kodu SQL, aby osiągnąć wydajność. Zapewniają także pewną przenośność używanej bazy danych, prawdopodobnie mają różną wydajność, np. W Postgres i MySQL, z powodu niektórych operacji wykorzystujących bardziej optymalne SQL specyficzne dla bazy danych.

I podobnie jak w przypadku języków wysokiego poziomu, bardzo ważne jest zrozumienie, w jaki sposób działa SQL, nawet jeśli jest to po prostu zmiana kolejności zapytań wykonywanych za pomocą wyżej wymienionych bibliotek SQL, aby osiągnąć pożądaną wydajność.

PS Wolałbym, aby to był komentarz, ale nie mam do tego wystarczającej reputacji.

Kyrylo Shpytsya
źródło
2

Jak zwykle jest to jedna z tych rzeczy, które zależą od wielu czynników. To prawda, że ​​z SQL można wiele zrobić. Istnieją również problemy z korzystaniem z niego i pewne praktyczne ograniczenia relacyjnych baz danych.

Jak zauważa Jared Goguen w komentarzach, testowanie i weryfikacja SQL może być bardzo trudna. Głównymi czynnikami, które do tego prowadzą, jest to, że nie można go (ogólnie) rozłożyć na komponenty. W praktyce złożone pytanie musi być rozpatrywane w całości. Innym czynnikiem komplikującym jest to, że zachowanie i poprawność SQL jest wysoce zależna od struktury i zawartości twoich danych. Oznacza to, że testowanie wszystkich możliwych scenariuszy (a nawet określenie, jakie są) jest często niemożliwe lub niemożliwe. Refaktoryzacja SQL i modyfikacja struktury bazy danych jest również problematyczna.

Innym dużym czynnikiem, który doprowadził do odejścia od SQL, są relacyjne bazy danych, które skalują się tylko w pionie. Na przykład, gdy budujesz skomplikowane obliczenia w SQL, aby uruchomić je w SQL Server, będą one wykonywane w bazie danych. Oznacza to, że cała ta praca wykorzystuje zasoby w bazie danych. Im więcej robisz w języku SQL, tym więcej zasobów będzie potrzebować baza danych zarówno pod względem pamięci, jak i procesora. Często wykonywanie tych czynności na innych systemach jest mniej wydajne, ale nie ma praktycznego ograniczenia liczby dodatkowych maszyn, które można dodać do takiego rozwiązania. Takie podejście jest tańsze i bardziej odporne na uszkodzenia niż budowanie potwornego serwera bazy danych.

Problemy te mogą, ale nie muszą dotyczyć danego problemu. Jeśli jesteś w stanie rozwiązać problem z dostępnymi zasobami bazy danych, być może SQL jest odpowiedni dla twojego obszaru problemów. Musisz jednak wziąć pod uwagę wzrost. Dzisiaj może być dobrze, ale kilka lat później koszt dodania dodatkowych zasobów może stać się problemem.

JimmyJames
źródło
Czy nie jest alternatywą dla potwornej bazy danych, jest po prostu potworną liczbą i różnorodnością systemów pomocniczych? Jaką odporność mają systemy pomocnicze, jeśli wszystkie zwisają z systemu podstawowego? A jeśli uzasadnieniem jest po prostu ograniczenie technologiczne systemu podstawowego, to często będzie to przedwczesna optymalizacja dla większości systemów biznesowych. SQL może być ogólnie pisany w sposób niepowiązany, jeśli zostanie to uznane za konieczne.
Steve
@ Steve Myślę, że tutaj popełniłeś błąd, zakładając, że musi istnieć jeden rdzeń systemu, z którego inni „zwlekają”.
JimmyJames
@ Steve Aby dać przykład, możesz zastąpić całą bazę danych systemu jedną bazą danych bez SQL (nie twierdzę, że jest to zawsze właściwy wybór, tylko że można to zrobić.) Tę bazę danych można następnie przechowywać w wielu systemy, nawet regiony geograficzne. Taki DB nie jest pomocniczy, jest hurtowym zamiennikiem SQL DB.
JimmyJames
@JimmyJames, zgodził się, ale gdy nie ma systemu podstawowego, może on tworzyć własne problemy, analizując zależności i zachowując spójność danych. To przede wszystkim powód dla monolitów - tworzą one pewną prostotę, a zatem pewne rodzaje analiz i wydajności utrzymania. Rozwiązania niemonolityczne wymieniają jedynie niektóre problemy lub koszty na inne.
Steve
@jmoreno Rzucanie zasobami na coś w celu zwiotczenia wraz z nim nie jest tym, co nazwałbym dobrą inżynierią: „w celu obsługi ogromnej ilości danych w witrynie i uruchomiono 9 000 instancji memcached w celu nadążenia za liczbą transakcji baza danych musi służyć ”. Czy bierzesz pod uwagę koszt swoich projektów, czy zakładasz, że ktoś wyda pieniądze, aby Twoje osobiste preferencje były wykonalne?
JimmyJames
2

Czy to pułapka na wzór DDD?

Pozwól mi najpierw wyjaśnić kilka nieporozumień.

DDD nie jest wzorem. I tak naprawdę nie określa wzorów.

Przedmowa do książki Erica Evana DDD stwierdza:

Czołowi projektanci oprogramowania uznawali modelowanie i projektowanie domen za kluczowe tematy od co najmniej 20 lat, ale zaskakująco niewiele zostało napisanych o tym, co należy zrobić i jak to zrobić. Chociaż nigdy nie została jasno sformułowana, filozofia pojawiła się jako podwodny prąd w społeczności obiektów, którą nazywam projektowaniem opartym na domenie.

[...]

Wspólną cechą tych sukcesów był bogaty model domenowy, który ewoluował poprzez iteracje projektowania i stał się częścią projektu.

Ta książka stanowi ramy do podejmowania decyzji projektowych i słownictwo techniczne do omawiania projektowania domen. Jest to synteza powszechnie przyjętych najlepszych praktyk oraz moich spostrzeżeń i doświadczeń.

Jest to więc sposób na podejście do tworzenia oprogramowania i modelowania domen oraz trochę technicznego słownictwa, które wspiera te działania (słownictwo, które obejmuje różne koncepcje i wzorce). To też nie jest coś zupełnie nowego.

Inną rzeczą, o której należy pamiętać, jest to, że model domeny nie jest implementacją OO, którą można znaleźć w twoim systemie - to tylko jeden ze sposobów wyrażenia go lub wyrażenia jego części. Model domeny to sposób, w jaki myślisz o problemie, który próbujesz rozwiązać za pomocą oprogramowania. To jak rozumiesz i postrzegasz rzeczy, jak o nich mówisz. To jest koncepcyjne . Ale nie w jakimś niejasnym sensie. Jest głęboki i wyrafinowany i jest wynikiem ciężkiej pracy i gromadzenia wiedzy. Jest on dalej udoskonalany i prawdopodobnie ewoluował w czasie, i obejmuje względy implementacyjne (niektóre z nich mogą ograniczać model). Powinny być udostępniane wszystkim członkom zespołu (i zaangażowani eksperci w dziedzinie) i powinien on decydować o sposobie wdrażania systemu, aby system ściśle go odzwierciedlał.

Nic w tym nie jest z natury pro lub anty-SQL, chociaż programiści OO są generalnie lepsi w wyrażaniu modelu w językach OO, a wyrażanie wielu koncepcji domen jest lepiej obsługiwane przez OOP. Ale czasami części modelu muszą być wyrażone w innym paradygmacie.

Zastanawiam się, co się dzieje, gdy mam bardzo złożone zapytania [...]?

Ogólnie mówiąc, istnieją tutaj dwa scenariusze.

W pierwszym przypadku jakiś aspekt domeny naprawdę wymaga złożonego zapytania i być może ten aspekt najlepiej wyraża się w paradygmacie SQL / relacyjnym - więc użyj odpowiedniego narzędzia do zadania. Odzwierciedlaj te aspekty myślenia w swojej domenie i języka używanego do komunikowania pojęć. Jeśli domena jest złożona, być może jest to część subdomeny z własnym ograniczonym kontekstem.

Innym scenariuszem jest to, że postrzegana potrzeba wyrażenia czegoś w SQL jest wynikiem ograniczonego myślenia. Jeśli dana osoba lub zespół zawsze był zorientowany na bazę danych, może to być dla nich, z powodu bezwładności, trudność dostrzeżenie innego sposobu podejścia. Staje się to problemem, gdy stary sposób nie spełnia nowych potrzeb i wymaga nieco myślenia po wyjęciu z pudełka. DDD, jako podejście do projektowania, częściowo polega na tym, jak znaleźć wyjście z tego pudełka, gromadząc i destylując wiedzę na temat domeny. Ale wydaje się, że wszyscy ignorują tę część książki i koncentrują się na niektórych z technicznego słownictwa i wymienionych wzorców.

Filip Milovanović
źródło
0

Sequel stał się popularny, gdy pamięć była kosztowna, ponieważ relacyjny model danych zapewniał możliwość normalizacji danych i skutecznego przechowywania ich w systemie plików.

Teraz pamięć jest stosunkowo tania, więc możemy pominąć normalizację i zapisać ją w formacie, w którym ją wykorzystujemy, lub nawet powielić wiele takich samych danych ze względu na szybkość.

Traktuj bazę danych jako proste urządzenie IO , które odpowiada za przechowywanie danych w systemie plików - tak, wiem, że trudno to sobie wyobrazić, ponieważ napisaliśmy wiele aplikacji z ważną logiką biznesową zapisanych w zapytaniach SQL - ale po prostu spróbuj wyobrazić sobie, że SQL Server to tylko kolejna drukarka.

Czy osadziłbyś generator PDF w sterowniku drukarki czy dodałeś wyzwalacz, który wydrukuje stronę dziennika dla każdego zamówienia sprzedaży wydrukowanego z naszej drukarki?

Zakładam, że odpowiedź brzmi „nie”, ponieważ nie chcemy, aby nasze aplikacje były powiązane z konkretnym typem urządzenia (nawet nie mówiąc o wydajności takiego pomysłu)

Czy w latach 70. i 90. baza danych SQL była wydajna? - Nie jestem pewien, w niektórych scenariuszach zapytanie asynchroniczne danych zwróci wymagane dane szybciej niż wiele połączeń w zapytaniu SQL.

SQL nie został zaprojektowany do skomplikowanych zapytań, został zaprojektowany do efektywnego przechowywania danych, a następnie zapewnia interfejs / język do przeszukiwania przechowywanych danych.

Powiedziałbym, że budowanie aplikacji wokół relacyjnego modelu danych przy użyciu skomplikowanych zapytań jest nadużywaniem silnika bazy danych. Oczywiście dostawcy silników baz danych są zadowoleni, gdy ściśle łączysz swoją firmę z ich produktem - z przyjemnością udostępnią więcej funkcji, które wzmocnią to powiązanie.

Fabio
źródło
1
Ale ciągle myślę, że SQL jest znacznie lepszy do ustawiania obliczeń niż jakikolwiek inny język. Z mojego punktu widzenia. twój przykład jest do góry nogami, używając C # do bardzo skomplikowanych operacji ustawiania z milionem wierszy i zaangażowanych sprzężeń używa niewłaściwego narzędzia, ale mogę się mylić.
Leonardo Mangano
@LeonardoMangano, kilka przykładów: z c # mogę porcjować miliony wierszy i obliczać je równolegle, mogę pobierać dane asynchronicznie i wykonywać obliczenia „w czasie” po zwrocie danych, z c # mogę wykonywać obliczenia przy niskim zużyciu pamięci przez wyliczenie wiersza po rzędzie. Posiadanie złożonej logiki w kodzie zapewni wiele opcji wykonywania obliczeń.
Fabio