¿El diseño dirigido por dominio es útil / productivo para dominios no tan complejos?

Al evaluar un proyecto potencial en el trabajo, sugerí que podría ser ventajoso utilizar un enfoque de diseño dirigido por dominio para su modelo de objeto. El proyecto no tiene un dominio excesivamente complejo, por lo que mi compañero de trabajo me arrojó esto:

Se ha dicho que DDD es favorable en los casos en que hay un modelo de dominio complejo ("... Se aplica siempre que estamos operando en un dominio complejo e intrincado" Eric Evans).

Lo que me hace perder es: ¿cómo define la complejidad de un dominio? ¿Se puede definir por el número de raíces agregadas en el modelo de dominio? ¿Es la complejidad de un dominio en la interacción de los objetos?

El dominio que estamos evaluando está relacionado con la publicación en línea y la gestión de contenido.

La complejidad de la lógica de negocios, llamada alternativamente el comportamiento de la aplicación, es el factor más importante. El segundo factor más importante es la brecha que existe entre el problema técnico y el vocabulario comercial utilizado para describir ese problema, ya que DDD se trata de crear un vocabulario compartido entre el negocio y el equipo de ingeniería.

Algunos de los patrones utilizados en DDD son generalmente útiles en la arquitectura de aplicaciones empresariales, como el patrón de repositorio, el contexto acotado y la arquitectura en capas. El hecho de que esté usando esos patrones no significa que esté haciendo un diseño impulsado por el dominio.

Si no hay mucho comportamiento, es decir, en su mayoría está almacenando datos y no está actuando sobre esos datos, puede haber mucho menos valor en la construcción de esa capa de dominio. En la administración de contenido, si todo lo que hace es aprobar y publicar, tal vez eso pueda representarse mediante indicadores en el sistema, en lugar de métodos de dominio. Pero cuando comienza a agregar un comportamiento adicional, la idoneidad de una capa de dominio completa se hace más evidente.

Si hablamos de gestión de contenido, aquí hay algunas reglas (imaginarias) que podrían comenzar a insinuar la necesidad de DDD:

• Si la historia está embargada hasta la fecha xx / aa / zz, publíquela para imprimirla y luego en la web; si no hay embargo, publíquelo en la web y póngalo a disposición para imprimir
• Haga que esta historia esté disponible detrás del muro de pago para los suscriptores pagos de inmediato; lanzamiento al público en general 2 semanas después.
• Después de escribir una historia, envíela a un editor para su revisión, revisión y aprobación. Cuando se apruebe, envíelo a producción. Si la producción corta la historia por razones de espacio, haga que una versión extendida esté disponible en línea.