Czy projektowanie oparte na domenach jest użyteczne / produktywne w przypadku mniej skomplikowanych domen?

Oceniając potencjalny projekt w pracy, zasugerowałem, że może być korzystne zastosowanie podejścia projektowego opartego na domenie do modelu obiektowego. Projekt nie ma nadmiernie złożonej domeny, więc mój współpracownik rzucił mi to:

Powiedziano, że DDD jest korzystny w przypadkach, gdy istnieje złożony model domeny („... Ma zastosowanie, gdy działamy w złożonej, skomplikowanej domenie” Eric Evans).

Zgubiłem się - jak zdefiniować złożoność domeny? Czy można to zdefiniować na podstawie liczby zagregowanych korzeni w modelu domeny? Czy złożoność domeny w interakcji obiektów?

Domena, którą oceniamy, jest powiązana z publikowaniem online i zarządzaniem treścią.

Najważniejszym czynnikiem jest złożoność logiki biznesowej, zwanej także zachowaniem aplikacji. Drugim najważniejszym czynnikiem jest to, jak duża jest luka między problemem technicznym a słownikiem biznesowym używanym do opisu tego problemu, ponieważ DDD polega na tworzeniu wspólnego słownictwa między biznesem a zespołem inżynierów.

Niektóre wzorce stosowane w DDD są ogólnie przydatne w architekturze aplikacji korporacyjnych, takie jak wzorzec repozytorium, ograniczony kontekst i architektura warstwowa. To, że używasz tych wzorców, nie oznacza, że ​​zajmujesz się projektowaniem opartym na domenie.

Jeśli nie ma zbyt wielu zachowań, co oznacza, że ​​przeważnie przechowujesz dane, a nie działasz na nich, budowanie tej warstwy domeny może mieć znacznie mniejszą wartość. Jeśli w zarządzaniu treścią wszystko, co robisz, to zatwierdzasz i publikujesz, być może może to być reprezentowane przez flagi w systemie, a nie metody domeny. Ale kiedy zaczniesz dodawać dodatkowe zachowanie, właściwość warstwy z pełną domeną stanie się bardziej widoczna.

Jeśli mówimy o zarządzaniu treścią, oto kilka (wymyślonych) reguł, które mogą zacząć wskazywać na potrzebę DDD:

• Jeśli historia jest objęta embargiem do daty xx / rr / zz, opublikuj w celu wydrukowania, a następnie w Internecie; jeśli nie ma embarga, opublikuj w Internecie i udostępnij do wydruku
• Natychmiast udostępniaj tę historię za zapłatą abonentom; wydanie do publicznej wiadomości 2 tygodnie później.
• Po napisaniu historii wyślij ją do edytora w celu weryfikacji, korekty i zatwierdzenia. Po zatwierdzeniu wyślij go do produkcji. Jeśli produkcja ogranicza historię z powodów związanych z przestrzenią, udostępnij rozszerzoną wersję online.