En mi opinión, DDD es tan pertinente hoy como siempre. La idea de que uno debe esforzarse por un lenguaje ubicuo, de modo que el dominio del código no esté separado del dominio como lo describen los expertos en el dominio, probablemente seguirá siendo una buena idea durante mucho tiempo, y hoy es más fácil enfocarse en el dominar primero y considerar la persistencia como un problema "secundario" de lo que solía ser. También es cierto que DDD requiere un importante esfuerzo de diseño, y su valor va a ser proporcional a la complejidad del dominio.
No he escrito ninguna aplicación usando la metodología, pero he estado leyendo mucho sobre Event Sourcing y CQRS últimamente, y ambos parecen ser un enfoque muy interesante que debería encajar bien con DDD (y generalmente son defendidos por personas quienes son proponentes de DDD).
Yo no lo encuentro en este momento, pero hay un video de entrevistas Eric Evans flotando en algún lugar en la web, usted puede estar interesado en ver this video of Eric Evans, que es una forma de retrospectiva sobre la metodología de unos pocos años después de escribir el libro, y lo que hubiera hecho de manera diferente ahora.
Creo que este es el enlace del video al que hizo referencia: http://www.infoq.com/presentations/ddd-eric-evans –
Gracias, eso es exactamente, por alguna razón mi Google-fu me traicionó antes, lo agregará a la respuesta en sí. – Mathias
Buscamos realmente una metodología que nos permita ofrecer a nuestros clientes garantías de inversión, no solo en términos de usabilidad y estabilidad si no se puede mantener de manera eficiente. Creo que DDD encaja muy bien en este aspecto, parece que una de las claves es determinar qué proyectos DDD puede agregar valor y aplicarlo allí, incluso aplicar solo en las áreas más complejas de los proyectos puede ser otra alternativa. – Manuel