Asegúrese de revisar los comentarios recientes del tío Bob sobre el papel del diseño en TDD .
El diseño impulsado por el dominio implica muchos patrones técnicos, que definen capas bien establecidas como la capa de aplicación, la capa de infraestructura, la capa de dominio y la capa de persistencia.
Udi Dahan: "Dios, cómo odio las capas". Pasa algo de tiempo discutiéndolo en su charla CQRS, pero diferente (la estratificación comienza a las 18m30s)
Deletrearía tu oración de manera ligeramente diferente; "DDD reconoce que hay una serie de preocupaciones comunes a la mayoría de las aplicaciones comerciales y que las soluciones a esas preocupaciones tienen vidas diferentes" .
Por ejemplo, las preocupaciones de dominio, por regla general, deben ser flexibles, especialmente cuando está personalizando una solución para un negocio en particular. Después de todo, el dominio se refiere a cómo la empresa hace negocios, es decir, cómo la empresa gana dinero y poder ofrecer mejoras comerciales rápidamente es un ingreso gratuito.
Por otro lado, probablemente no necesite cambiar el componente de persistencia con frecuencia. La solución de base de datos que funcionó la última versión probablemente también funcionará en esta versión.
Las preocupaciones de la aplicación están en algún punto intermedio; tienden a ser estables para que los usuarios no necesiten aprender una nueva aplicación con cada lanzamiento.
Además, puede haber múltiples implementaciones para resolver cualquier problema. Por ejemplo, la aplicación puede necesitar solo una instantánea de su estado actual; basta con guardar un archivo en el disco. Y en sus primeras iteraciones, eso puede ser todo lo que el dominio necesita también. Pero eventualmente llega una historia que requiere soporte de consultas ad-hoc, y usted reconoce que configurar una base de datos relacional será mucho más fácil que implementar una desde cero. Y luego está esta característica que funcionaría mejor en una base de datos gráfica.
Mientras tanto, el CTO quiere una versión de la aplicación que se ejecute en su teléfono; el CEO acaba de escuchar de un tipo que publicar una API es lo más importante.
Además, el equipo de ventas utiliza un modelo diferente, por lo tanto, dénos la misma aplicación, con un modelo diferente. Oh, pero estamos viajando mucho, por lo que nuestra versión debe funcionar cuando estamos desconectados y sincronizarnos más tarde ...
En otras palabras, aplica los patrones tácticos de ddd no implementando marcadores de posición vacíos y suponiendo que se completarán más tarde, sino que al reconocer cuándo está cruzando las corrientes "Oye, ese es el código de persistencia en mi modelo de dominio, no debo ser hecho refactorización todavía ".
