Является ли Domain Driven Design полезным / продуктивным для не очень сложных доменов?

Оценивая потенциальный проект на работе, я предположил, что было бы выгодно использовать подход к проектированию на основе предметной области для его объектной модели. У проекта нет слишком сложного домена, поэтому мой коллега бросил в меня это:

Было сказано, что DDD является благоприятным в тех случаях, когда существует модель сложной области («... она применяется всякий раз, когда мы работаем в сложной, сложной области», Эрик Эванс).

На чем я потерялся - как вы определяете сложность домена? Может ли он быть определен числом агрегатных корней в доменной модели? Есть ли сложность домена во взаимодействии объектов?

Домен, который мы оцениваем, связан с онлайн-публикацией и управлением контентом.

Сложность бизнес-логики, альтернативно называемая поведением приложения, является наиболее важным фактором. Второй по важности фактор - это большой разрыв между технической проблемой и бизнес-словарем, который используется для описания этой проблемы, поскольку DDD занимается созданием общего словаря между бизнесом и командой инженеров.

Некоторые из шаблонов, используемых в DDD, обычно полезны в архитектуре корпоративных приложений, такие как шаблон репозитория, ограниченный контекст и многоуровневая архитектура. Только то, что вы используете эти шаблоны, не означает, что вы делаете дизайн, управляемый доменом.

Если поведение не слишком велико, то есть вы в основном храните данные и не действуете на этих данных, может быть гораздо меньшая ценность в построении этого уровня домена. В управлении контентом, если все, что вы делаете, это утверждаете и публикуете, возможно, это может быть представлено в системе флагами, а не методами домена. Но когда вы начинаете добавлять дополнительное поведение, уместность полноценного доменного слоя становится более очевидной.

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

• Если история запрещена до даты xx / yy / zz, опубликуйте для печати, а затем в Интернете; если нет эмбарго, опубликовать в Интернете и сделать доступными для печати
• Сделайте эту историю доступной за платным доступом к платным подписчикам немедленно; релиз для широкой публики через 2 недели.
• После написания статьи отправьте ее редактору для доработки, проверки и одобрения. После утверждения отправьте его на производство. Если производство сокращает историю по космическим причинам, сделайте расширенную версию доступной онлайн.