En este post introduciré estilos y patrones de arquitectura más interesantes y recomendables que puedes aplicar con DDD mencionados por Vaughn Vernon en «Implementing Domain-Driven Design”.

No se trata de una lista cerrada, ya que el enfoque táctico de Domain-Driven Design no requiere la utilización específica de ningún tipo de patrón o arquitectura: la verdadera importancia de cada Bounded Context reside en su Core Domain o modelo de dominio, independientemente de como se comunique con el resto de componentes de la aplicación, siempre y cuando se cumplan las buenas prácticas y los principios de calidad apropiados.
more →

En el post anterior vimos los primeros pasos estratégicos y cómo disgregábamos la complejidad del negocio en Domains, Subdomains y Bounded Contexts.

Cada Bounded Context contiene o dispone de la tecnología, lenguaje de programación y arquitectura mínima necesaria para satisfacer los requerimientos de negocio de su contexto mediante un modelo de dominio. Las relaciones existentes entre Bounded Contexts se denominan Context Maps y las reglas necesarias para mapear/traducir un modelo de dominio de un determinado contexto a otro: Translation Map.

Una vez identificados los Bounded Contexts, deberemos establecer según necesidades de cada caso el tipo de relación entre ellos, marcando la dirección de flujo de información mediante Upstream (exposición de servicios) y Downstream (consumidor de servicios):

Estoy inmerso en la lectura de «Implementing Domain-Driven Design» de Vaughn Vernon. Llevo algunos pocos capítulos y he decidido, a modo de seguimiento y aprendizaje, empezar a escribir una serie de post para compartir con la comunidad algunas reseñas de lo que creo interesante. Siéntete libre de hacer tus comentarios 🙂

El diseño no es sólo cómo se ve o cómo se siente. El Diseño es cómo funciona. Steve Jobs

more →