W jaki sposób to ma sens?
Krótka odpowiedź: nie .
Dłuższa odpowiedź: ciężkie wzorce do opracowania modelu domeny nie dotyczą tych części rozwiązania, które są tylko bazą danych.
Udi Dahan miał ciekawe spostrzeżenie, które może pomóc to wyjaśnić
Dahan uważa, że usługa musi mieć zarówno funkcjonalność, jak i pewne dane. Jeśli nie ma danych, jest to tylko funkcja. Jeśli wszystko, co robi, to wykonywanie operacji CRUD na danych, to jest to baza danych.
W końcu model domeny ma zapewnić, że wszystkie aktualizacje danych zachowają bieżący niezmiennik biznesowy. Innymi słowy, model domeny jest odpowiedzialny za zapewnienie poprawności bazy danych, która działa jak system zapisu .
Kiedy masz do czynienia z systemem CRUD, zwykle nie jesteś systemem zapisu danych. Świat rzeczywisty to księga rekordów, a twoja baza danych to tylko lokalna pamięć podręczna reprezentacji świata rzeczywistego.
Na przykład większość informacji pojawiających się w profilu użytkownika, takich jak adres e-mail lub numer identyfikacyjny wydany przez rząd, ma źródło prawdy, które mieszka poza Twoją firmą - to administrator poczty innej osoby przypisuje i odwołuje adresy e-mail, a nie twoja aplikacja. To rząd przypisuje numery SSN, a nie Twoja aplikacja.
Dlatego zwykle nie będziesz przeprowadzać walidacji domen na danych przychodzących do ciebie ze świata zewnętrznego; możesz mieć kontrole, aby upewnić się, że dane są poprawnie sformułowane i odpowiednio zdezynfekowane ; ale to nie twoje dane - Twój model domeny nie otrzymuje weta.
W podejściu DDD z wykorzystaniem warstw wydaje się, że operacje CRUD przechodzą przez warstwę domeny. ale przynajmniej w naszym przypadku nie wydaje się to mieć sensu.
Tak jest w przypadku, gdy baza danych jest księgą rekordów .
Ouarzy tak to ujął .
Pracując nad wieloma starszymi kodami, obserwuję często popełniane błędy w identyfikowaniu tego, co jest w domenie, a co na zewnątrz.
Aplikację można uznać za CRUD tylko wtedy, gdy wokół modelu danych nie ma logiki biznesowej. Nawet w tym (rzadkim) przypadku model danych nie jest modelem domeny. Oznacza to po prostu, że ponieważ nie ma w tym żadnej logiki biznesowej, nie potrzebujemy żadnej abstrakcji, aby nią zarządzać, a zatem nie mamy modelu domeny.
Używamy modelu domeny do zarządzania danymi należącymi do domeny; dane spoza domeny są już zarządzane gdzie indziej - po prostu buforujemy kopię.
Greg Young wykorzystuje systemy magazynowe jako główną ilustrację rozwiązań, w których księga rekordów znajduje się gdzie indziej (np. Podłoga magazynu). Implementacja, którą opisuje, jest bardzo podobna do twojej - jedna logiczna baza danych do przechwytywania wiadomości otrzymanych z magazynu, a następnie osobna logiczna baza danych buforująca wnioski wyciągnięte z analizy tych wiadomości.
Więc może mamy tutaj dwa ograniczone konteksty? Każdy z innym modelem dlainvestment account
Może. Nie chciałbym oznaczać go jako kontekstu ograniczonego, ponieważ nie jest jasne, jaki inny bagaż jest z nim związany. Możliwe, że masz dwa konteksty, może to być jeden kontekst z subtelnymi różnicami we wszechobecnym języku, którego jeszcze nie znasz.
Możliwy test lakmusowy: ilu ekspertów domeny potrzebujesz dwóch ekspertów domeny, aby objąć to spektrum, lub tylko jednego, który mówi o komponentach na różne sposoby. Zasadniczo możesz odgadnąć, ile masz ograniczonych kontekstów, cofając prawo Conwaya.
Jeśli uważasz, że ograniczone konteksty są dostosowane do usług, może to być łatwiejsze: czy możesz mieć możliwość niezależnego wdrożenia tych dwóch funkcji? Tak sugeruje dwa ograniczone konteksty; ale jeśli muszą być zsynchronizowane, może to tylko jeden.
