Чи корисний / продуктивний дизайн домену для не так складних доменів?

Оцінюючи потенційний проект на роботі, я припустив, що може бути вигідним використовувати підхідний дизайн підхід до його об'єктної моделі. Проект не має надмірно складного домену, тому мій колега кинув це на мене:

Було сказано, що DDD сприятливий у випадках, коли існує складна модель домену ("... Він застосовується, коли ми працюємо у складному, хитромудрому домені" Ерік Еванс).

Що я втрачаю, це - як ви визначаєте складність домену? Чи можна його визначити за кількістю сукупних коренів у доменній моделі? Чи є складність домену у взаємодії об’єктів?

Домен, який ми оцінюємо, пов’язаний з онлайн-публікацією та керуванням контентом.

Складність ділової логіки, яку альтернативно називають поведінкою програми, є найважливішим фактором. Другий найважливіший фактор - скільки існує розрив між технічною проблемою та бізнес-словником, який використовується для опису цієї проблеми, оскільки DDD полягає у створенні спільного словника між бізнесом та інженерною командою.

Деякі з моделей, що використовуються в DDD, як правило, корисні в архітектурі прикладних програм підприємства, такі як шаблон сховища, обмежений контекст та шарувата архітектура. Тільки тому, що ви використовуєте ці шаблони, не означає, що ви робите дизайн, керований доменом.

Якщо поведінки не так багато, що означає, що ви здебільшого зберігаєте дані, і не дієте на ці дані, може бути набагато менше значення при створенні цього доменного шару. Якщо в управлінні вмістом все, що ви робите, схвалюєте та публікуєте, можливо, це може бути представлено прапорами в системі, а не методами домену. Але коли ви починаєте додавати додаткову поведінку, доцільність повноцінного шару домену стає більш очевидною.

Якщо ми говоримо про управління вмістом, ось деякі (уявлені) правила, які можуть почати натякати на необхідність DDD:

• Якщо історія ембаргована до дати xx / yy / zz, опублікуйте для друку, а потім в Інтернеті; якщо немає ембарго, опублікуйте в Інтернеті та зробіть його доступним для друку
• Негайно зробіть цю історію доступною за платною стіною платним абонентам; випуск для широкої громадськості через 2 тижні.
• Після написання розповіді надсилайте її до редакції для доопрацювання, коректури та затвердження. Коли це буде затверджено, надішліть його на виробництво. Якщо виробництво скоротить історію з космічних причин, зробіть розширену версію доступною в Інтернеті.