Domain Driven Design – Value Object

Value Object czyli obiekt wartości to drugi, zaraz po encji, najważniejszy element podejścia DDD. Różnią się od encji tym, że nie posiadają tożsamości. Nie nadajemy im identyfikatora, ponieważ nie interesuje nas ich cykl życia, a jedynie przenoszona wartość.

Obiekty te są definiowane przez ich atrybuty. Dla przykładu obiektem wartości będą liczby np. 3, 15, 30 albo ciągi znaków jak nazwiska czy ulice. Value objecty mogą być też złożone np. adres, który będzie wartością składającą się z atrybutów: ulica, numer domu, kod pocztowy i miasto. Tworząc jednak wartości złożone, programista powinien się głębiej zastanowić czy na pewno kontekst nie wymusza na nim śledzenia tożsamości. W takiej sytuacji dane pojęcie powinno stać się encją.

Bardzo ważną cechą obiektów wartości jest to, że powinny być one tak zaimplementowane, aby w trakcie ich życia nie dało się zmienić ich stanu. Jeśli dana wartość się zmieni, powinna zostać zastąpiona całkiem nowym obiektem lub kopią obiektu. W implementacji możemy uzyskać to poprzez hermetyzację obiektu, ustawiając atrybut prywatny w konstruktorze jednocześnie nie udostępniając metody definiującej(seter).

Przykład

W przypadku sklepu internetowego adres będzie wartością, ponieważ złożenie zamówienia przez dwie rodziny mieszkające pod tym samym adresem nie jest problematyczne, wręcz logiczne i naturalne. Jednak w przypadku elektrowni adres będzie encją, ponieważ jeśli jedna rodzina złożyła już zamówienie na podłączenie prądu pod dany adres, to gdy druga rodzina również złoży takie zamówienie, elektrownia musi zweryfikować czy pod takim adresem nie zostało już zamontowane przyłącze. W tej sytuacji adres musi mieć tożsamość – identyfikator, po którym zostanie jednoznacznie zidentyfikowany, a następnie zostanie dla niego zweryfikowany stan przyłącza.

Obiekty wartości są bardzo często wykorzystywane do opisu modelu, jednak sprawiają architektom duży kłopot. W wielu przypadkach sytuacja wymaga głębszego zastanowienia i zagłębienia się w kontekst, aby zdecydować czy dany element domeny powinien być encją, czy wartością. Vaughn Vernon wyróżnia cechy wartości, które pozwalają ułatwić decyzję, w jaki sposób zaprojektować element modelu.

Jak rozpoznać value object?

Zgodnie z jego zaleceniami podczas projektowania architekt musi zastanowić się nad kontekstem wykorzystania pojęcia dziedziny. Przeanalizować czy wraz z rozwojem języka wszechobecnego pojęcie nie zmienia się na tyle, że zostaje mu nadana tożsamość. Architekt powinien zweryfikować czy większość odpowiedzi na poniższe pytania będzie twierdząca, opisując analizowane pojęcie. Jeśli tak, to oznacza, że dane pojęcie będzie wartością:

  • Czy opisuje ona przedmiot należący do dziedziny lub określa go ilościowo?
  • Czy jest niezmienna?
  • Czy składa się z różnych atrybutów, które mogą stworzyć całość
  • Czy przy zmianie opisu lub pomiaru pojęcia zmienia się w całości czy tylko cześć jej atrybutów?
  • Czy zawiera w sobie wartość, która może być porównywana z innymi z wykorzystaniem pojęcia równości?
  • Czy jej użycie jest pozbawione skutków ubocznych? (ang. Side-Efect-Free Behavior)

Wartość może być elementem encji. Podejście DDD zaleca, aby identyfikator encji również był obiektem wartości. Zamiast przekazywać np. uuid jako ciąg znaków czy id w formie integera, powinno się go obudować obiektem wartości, ponieważ mamy większą kontrolę nad postacią obiektową oraz zapewnia nam to większe bezpieczeństwo danych m.in. poprzez typowanie.

Zrozumiałeś już czym są value objecty? Jeśli masz jeszcze jakieś wątpliwości, pytaj śmiało w komentarzu

Podobne posty

Jestem programistką, która lubi mieć ręce pełne roboty. Do życia potrzebuje komputera z internetem i kubka gorącej kawy. Więcej na stronie o mnie.

Comments

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here