Please enable JavaScript.

Coggle requires JavaScript to display documents.

DDD domain model elements - Coggle Diagram

- - - - Technika analizy przypadków użycia
        
        powstrzymanie się od wstępnego grupowania pojęć w „worki” do momentu analizy przypadków użycia/ operacji domenowych i grupowania ich pod kątem spójnych jednostek zmiany
- - - - The code in the domain service is more testable than in the application service, when separated. (fewer external deps)
      - we prevent domain knowledge leakage and keep all domain logic within the domain model boundary which may be helpful for readability.
    - - Not a natural part of an Entity or Value Object
      - Have an interface defined in terms of other domain model elements
      - are stateless but may have side effects
  - - - Klasy z tej warstwy zwykle testujemy w podejściu end-
        -to-end, ponieważ mnogość możliwych scenariuszy przejścia praktycznie uniemożliwia wysokie pokrycie testami
        jednostkowymi – stosunek włożonej pracy do poziomu
        redukcji ryzyka jest zwykle niekorzystny.
      - Dodatkowym kosztem testów jednostkowych w tej warstwie jest konieczność zaślepiania (fake/stub/mock) dużej ilości zależności
    - - orkiestrację domeny – scenariusz sterowania obiektami domenowymi
      - technikalia takie jak transakcje i bezpieczeństwo
      - dodatkową logikę typową dla tej konkretnej aplikacji
- - - - uzyteczne dla aplikacji klasy „przeglądarka do bazy danych”
      - W tych miejscach systemu decydujemy się na
        kompromisy jakościowe (jakość modelu, jakość kodu) –
        świadomie zaciągamy dług techniczny.
      - Przykładowo w naszym systemie możemy zdecydować
        się na wprowadzenie systemu komentarzy. Zakładając,
        że jego działanie nie jest krytyczne dla powodzenia całego przedsięwzięcia biznesowego, klasyfikujemy ten podsystem jako Supporting Domain. Warto zwrócić uwagę, że w innym kontekście podsystem komentarzy może być krytyczny (ponieważ np. buduje zaufania) – wówczas traktujemy go jako Core Domain
      - to funkcjonalności, które nie są krytyczne i możemy zaryzykować niższą jakość ich kodu. W dużych projektach mogą być outsourcowane.
    - - jest głównym komponentem systemu ponieważ dostarcza największą wartość i być może stanowi o przewadze nad konkurencją. Tylko w Core Domain stosujemy techniki DDD oraz inwestujemy w nią najlepszych ludzi.
      - W DDD zakładamy, że modelowanie Core Domain stanowi największe wyzwanie w cyklu produkcji systemu.
      - słaby model stanowi wysokie ryzyko niepowodzenia przedsięwzięcia
      - Techniki DDD mają zastosowanie (jako inwestycja) w Core Domain.
    - - to specyficzne pod-domeny, w przypadku których warto użyć gotowych rozwiązań integrując się z nimi poprzez specjalną warstwę anticorruption-layer, która odcina nasz model od specyfiki modeli Generic. Przykładem może być biblioteka operująca na grafach lub zakup pod-modułu księgowości.
      - Pewne domeny są generyczne w stosunku do naszej głównej domeny. Przykładowo tworząc system służący do handlu zawartością multimedialną, nie będziemy skupiać wysiłku mentalnego, pracując nad modułem fakturowania. Fakturowanie jest krytyczne (zależy nam na jakości tego modułu), ale a) nie stanowi ono głównej wartości, oraz b) tego typu systemy istnieją na rynku (zarówno Open Source, jak i komercyjnym). Dlatego przykładowe fakturowanie możemy potraktować jako Generic Domain.
    - - While Subdomain is the problem space concept, the distinct area of your domain which can be easily isolated from other areas (subdomains), business broken down by you, while Bounded Context is the solution space concept to that problem: the code and other artifacts you create in order to address it with software.
      - Analogy to the carpet and a floor in a room: a carpet wall-to-wall is a bounded context, a floor is a subdomain. Wall-to-wall carpet fits ideally, while sometimes you may have a different carpet which doesn't fir ideally - this would be a legacy system, which didn't follow changes as fast as it could.