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.