fbpx

Domain Driven Design – Encja

Domain Driven Design – Encja

Czym jest DDD już wiadomo z ostatniego wpisu. Dzisiaj przyszedł czas na więcej szczegółów. Pierwszy krok to obiekty, które są klockami, z których buduje się model domenowy. Największy klocek to encja, którą przybliżę Ci w tym poście.

Czym jest encja?

Encje są podstawowym elementem modelu dziedziny. To obiekty, które posiadają identyfikator — tożsamość, dzięki której jesteśmy w stanie je jednoznacznie zidentyfikować. Zawierają w sobie również logikę biznesową.

Jednak z zawieraniem logiki trzeba uważać przy implementacji. Nie chodzi tutaj, aby całe procesy umieszczać w encjach, a jedynie niezbędne procesy wpływające jedynie na stan wewnętrzny encji. Ich ciągłość w całym cyklu życia obiektu jest nierozerwalna, ale postać może ulec zmianom.

Tożsamość powinna być niezależna od atrybutów czy asocjacji. W implementacji może to być np. obiekt osoby, umowy czy transakcji. Wynika z tego, że wszystkie najważniejsze pojęcia, które pojawiają się jako RZECZOWINIKI w języku wszechobecnym(o którym w kolejnych postach) programista implementujący model powinien definiować w postaci encji.

Przykład

Dobrym przykładem, aby zrozumieć, co w danym modelu będzie encją, może być system do rezerwacji biletów na koncert.

W pierwszym przypadku, gdy koncert będzie odbywał się np. w filharmonii, gdy osoba kupi bilet system przypisze jej numer siedzenia, który wybrała, ponieważ jest to ważna informacja w kontekście tego koncertu. Przy zakupie takiego biletu klient wybiera sobie jednoznacznie miejsce identyfikowane przez numer, który będzie tożsamością siedzenia.

Drugi przypadek, to koncert odbędzie się w klubie, gdzie nie ma miejsc siedzących albo wydarzenie, na którym będzie obowiązywał wolny wstęp. System w tej sytuacji nie potrzebuje dokładnie rozróżniać miejsc, ponieważ widzowie zajmą to, które będzie aktualnie wolne.

Na koncercie w pierwszym przykładzie, miejsce będzie w modelu dziedzinowym encją, ponieważ ważna jest dla nas jego tożsamość, czyli numer. System potrzebuje śledzić jego stan np. by sprawdzać zajętość. W drugim już nie. Miejsce możemy zaimplementować jako wartość, o której więcej informacji znajdzie się w następnym poście.

Tożsamość

Podczas budowania obiektu encji trzeba zwrócić szczególną uwagę na jej atrybuty. Powinna ona zawierać jedyne te cechy, które są niezbędne do jej działania oraz odpowiadają na potrzebę biznesową. Utrzymanie tożsamości i ciągłości encji jest bardzo trudnym zadaniem.

Języki programowania posiadają bardzo różne sposoby na sprawdzenie czy dwa obiekty to ten sam obiekt. Zwykle dzieje się to poprzez odniesienia do miejsca w pamięci. Jednak w podejściu domenowym to nie wystarcza. Encja powinna mieć silniejszą tożsamość, która może być atrybutem lub zbiorem atrybutów, choć i to często jest niewystarczające. Najczęściej stosowaną techniką jest nadanie obiektowi ID, czyli liczby lub ciągu znaków, który musi być unikalny w skali systemu.

Podejście domenowe zaleca aby ID encji było obiektem wartości. Takie podejście ma wiele zalet. Jedna z nich to pewność, że obiekt nie zostanie spłaszczony, czyli nawet gdy zostanie poddany serializacji, zachowuje swoją strukturę po zapisaniu i odtworzeniu z bazy.

Podczas projektowania encji architekt musi zastanowić się, w jaki sposób będzie nadawana tożsamość. Wyróżnia się kilka podejść:

  1. Użytkownik dostarcza identyfikator do systemu.
  2. Jest generowany przez system.
  3. Jest zwracany przez bazę danych lub inny sposób utrwalania obiektów.
  4. Określany jest przez kontekst ograniczony.

Encja stała się już dla Ciebie zrozumiała? Może masz jakieś dodatkowe pytania? Pisz śmiało w komentarzu!

Zgarnij darmowy ebook i cotygodniową dawkę wiedzy

.
Magdalena Limanówka-Kuciel
magdalena@panizkomputerem.pl

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.