DDD: ¿Cómo dividir la aplicación en Contextos delimitados además de la muestra de comercio electrónico?

Question

Tenemos una aplicación bastante grande aquí y estoy considerando refactorizarla un poco para seguir la guía de DDD.

Por ahora, el problema número uno es Contextos acotados y Mapas de contexto. Tal vez no lo asimile, pero me parece imposible hacer una división. Por ejemplo, tenemos un objeto de usuario en todas partes y es exactamente el mismo objeto de usuario: nombre de visualización, id y roles. Hay otro ejemplo: tenemos el objeto CatalogItem para ayudarnos a categorizar otras entidades en cualquier lugar. ¿Tenemos que introducir dependencias de contexto delimitado? ¿Hay alguna guía para este asunto además de esa molesta muestra de comercio electrónico?

Answer 1

Descubrí que, al principio, los contextos delimitados y las raíces agregadas parecían el concepto más fácil en DDD. Esto es hasta que realmente llegues a implementar una aplicación DDD con un problema del mundo real. No hay una respuesta fácil aquí. Depende totalmente de los requisitos de su empresa (escalabilidad, disponibilidad, latencia, coherencia, etc.). La solución "correcta" es la que equilibra estas preocupaciones para que se ajuste mejor a sus necesidades.

Con el ejemplo que das, hay algunas opciones:

• Una gran contexto acotado
• contextos delimitados por separado, con datos duplicados (posiblemente implementado usando un/suscripción sistema de mensajería publicar)
• tire de Usuarios y CatalogItems en su propio contexto limitado y tienen otros contextos acotadas a acceder a través de un servicio

una cosa a tener en cuenta es que queryi Las necesidades de ng a menudo son muy diferentes a las necesidades de "escritura". A menudo puede simplificar el diseño de la aplicación para tener contextos delimitados separados puramente para consultas. Si parece que esto podría aplicarse, mira en CQRS.