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!

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

  1. Czy mógłbym więc założyć, że encja jest to instancja reprezentująca obiekt w bazie danych, który posiada operacje/zachowanie pozwalające zmieniać swój stan? Ma bowiem unikalne Id i może być jednoznacznie zidentyfikowany. Chciałbym również zapytać, co ma Pani na myśli pod pojęciem

    “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.”

    tzn, że obiekt ten ma reprezentować więcej niż jeden unikalny atrybut w bazie danych?

    Z góry dziękuję za odpowiedź
    Pozdrawiam!

    PS: Fajny artykuł!

    • 1. Czy mógłbym więc założyć, że encja jest to instancja reprezentująca obiekt w bazie danych, który posiada operacje/zachowanie pozwalające zmieniać swój stan?
      Nie do końca, jest to bardzo duże uroszczenie encji domenowej. Niestety niefortunna nazwa wszystkich prowadzi na ten trop. DDD odcina się od zapisu danych, obiekty domenowe powinny kończyć się na metodzie save() i tyle je obchodzi. Implementacja metody save jest już poza domeną i w jaki sposób ją zapiszesz to już Twoja architektoniczna decyzja. Jeśli zdecydujesz się odwzorować encję domenową w encji/obiekcie w bazie danych 1:1 to możesz tak zrobić, ale UWAGA -> jeśli robisz to świadomie i nie używasz np. encji doctrinowej jako encji domenowej tylko posiadasz dwa różne obiekty, które mapujesz na siebie. Wtedy warstwa domeny jest oddzielona od warstwy trzymania danych.

      2. tzn, że obiekt ten ma reprezentować więcej niż jeden unikalny atrybut w bazie danych?
      Może ale nie musi. ID może to być zwykły UUid lub string, jednak zaleca się żebyś nie typował wszystkich IDików Twoich encji na UUid/string, ale powinno to wyglądać tak, że masz obiekt ProductId, który zawiera tylko property value i potem już w obiekcie domenowym Product property id typujesz na obiekt ProductId, a nie na Uuid/string. Wtedy Twoje ID jest value objectem. Oczywiście możesz, ale nie musisz, tworzyć value objecty z więcej niż jednym property. Jednak osobiście nie spotkałam się z sytuacją, kiedy value object opisujący ID encji zawierałby coś więcej niż value.

ZOSTAW ODPOWIEDŹ

Please enter your comment!
Please enter your name here