DDD: Czy niezmienne obiekty mogą być również bytami?

9

Przeczytałem niezliczoną liczbę postów na temat różnic między obiektami a obiektami Value i chociaż myślę, że przynajmniej koncepcyjnie rozumiem, jak te dwie rzeczy się różnią, wydaje się, że w niektórych z tych postów autorzy uważają określoną koncepcję domeny za VO po prostu dlatego, że jest niezmienny (a zatem jego stan nigdy się nie zmieni, przynajmniej w ramach tego konkretnego modelu domeny).

Czy zgadzasz się, że jeśli stan obiektu nigdy nie zmieni się w ramach określonego modelu domeny, to ten obiekt nigdy nie powinien być bytem? Dlaczego?

bckpwrld
źródło
Muszę nauczyć się DDD, aby móc inteligentnie odpowiedzieć na niektóre z tych pytań. Podejrzewam, że trudność, z jaką wielu programistów ma takie proste pojęcia, wynika z błędnego przekonania, że ​​DDD jest metodologią programowania.
Robert Harvey

Odpowiedzi:

4

Idąc po książce (Evans, 2004), „Obiekt zdefiniowany przede wszystkim przez swoją tożsamość nazywa się ENTITY”. Ta definicja jest niezależna od tego, czy obiekt jest zmienny czy niezmienny. Myślę, że znacznie mniej prawdopodobne jest, aby niezmienny obiekt był bytem w danej domenie, więc jest to przydatna heurystyka do decydowania, czy obiekt jest „obiektem wartości” czy „bytem”, ale nie jest to część definicji.

Załóżmy na przykład, że masz podmiot reprezentujący pracownika, który może, ale nie musi, mieć bezpośredniego przełożonego. Jeśli zdecydujesz się reprezentować ideę braku bezpośredniego przełożonego jako odniesienia do obiektu nadzorcy „zerowego”, wówczas obiekt nadzorcy „zerowy” jest racjonalnie uważany za byt. Prawdopodobnie możesz sprawić, że ten „zerowy” obiekt będzie niezmienny.

Aidan Cully
źródło
1
+1 Menedżer może być tylko do odczytu (niezmienny) w określonym kontekście lub subdomenie, ale to nie znaczy, że nie ma tożsamości.
Adrian Schneider
Wybacz mi, że jestem gęsty, ale nie do końca rozumiem twój przykład przełożonego. Czy mówisz, że w domenie mielibyśmy dwie koncepcje związane z przełożonym? Jedna koncepcja reprezentowałaby osoby nadzorujące, które mają pracowników, których nadzorują (w kodzie ta koncepcja byłaby implementowana jako zmienna klasa Supervisor), podczas gdy druga koncepcja opisywałaby osobę nadzorującą, która nie nadzoruje żadnych pracowników (i ta koncepcja byłaby implementowana jako kod zerowy) ?
bckpwrld
@bckpwrld Nie, on z pewnością oznacza obiekt zerowy .
maaartinus
2

Sposób, w jaki to przeczytałem, jest taki, że obiekt wartości jest obiektem, który nie ma własnej tożsamości i nie ma nic wspólnego ze zmienianiem lub nie zmienianiem stanu. To czyni różnicę między jednostką a obiektem wartości, że jednostka ma klucz podstawowy, podczas gdy obiekt wartości nie; będzie miał klucz obcy do podmiotu, do którego należy.

http://lostechies.com/joeocampo/2007/04/23/a-discussion-on-domain-driven-design-value-objects/

Nadal mogę zmieniać właściwości obiektu wartości, ale nie trzeba go nigdy identyfikować niezależnie od jego istoty.

Kevin
źródło
Włączyłem terminologię z relacyjnych baz danych (klucz podstawowy) jako tożsamość jako metaforę, proszę nie przyjmuj tego dosłownie
Kevin
O ile mi wiadomo, nawet jeśli w kodzie VO są reprezentowane przez zmienny typ (w ten sposób instancje tego typu mogą mieć modyfikowane swoje właściwości), koncepcyjnie te VO są nadal niezmienne. Zatem zmiana właściwości instancji reprezentującej konkretną VO oznacza, że ​​teraz ta sama instancja reprezentuje inną VO. Innymi słowy, VO są koncepcyjnie zawsze niezmienne
bckpwrld