
Domain-Driven Design in PHP
Reviews

Ya leí el libro en sus primeras versiones pero no lo había leído en esta última, modifico el rating que le di de 2 a 4 estrellas. Dejo un breve resumen con algunos apuntes del libro: El libro habla sobre DDD, una manera de escribir software que nos ayuda a tener éxito entendiendo y construyendo diseños de software. DDD nos provee de herramientas estratégicas y tácticas que nos ayudan a escribir software de alta calidad que alcance los objetivos del negocio. DDD está basado en tres pilares: * El lenguaje ubicuo: Expertos de dominio y desarrolladores de software trabajan juntos en construir un lenguaje común en las distintas áreas del negocio. * Diseño estratégico * Diseño táctico: Nos provee de herramientas para escribir un software con menos errores y mayor calidad. Junto al lenguaje ubicuo tenemos los Contextos Delimitados, estos son límites conceptuales en nuestro sistema. El lenguaje ubicuo dentro de un contexto tiene un significado específico que no tiene porqué darse en otro contexto del negocio. Para construir aplicaciones complejas, uno de los requisitos clave es tener un diseño arquitectónico que encaje con las necesidades de nuestra aplicación. El libro nos dice que una de las ventajas de DDD es que no está atado a ninguna arquitectura en concreto. A continuación, expone algunas arquitecturas que encajan bien con PHP: * Arquitectura por Capas * Cada capa está altamente acoplada a sus capas inferiores (UI > Aplicación > Dominio > Infraestructura) * Arquitectura Hexagonal * Sigue una estructura similar a la Arquitectura por Capas * Soluciona el problema del acoplamiento invirtiendo las dependencias utilizando el Principio de Inversión de Dependencias * El modelo deja de estar acoplado a la infraestructura * Command Query Responsibility Segregation (CQRS) * Sigue una estructura similar a la Arquitectura Hexagonal * Soluciona el problema de tener muchos métodos en los Repositorios tratándolos como parte de la infraestructura * Separa el modelo en dos: * Modelo de escritura * Se encarga de las escrituras * Toma la responsabilidad sobre el comportamiento del modelo * Cada vez que alguien lanza un comando, escribe en la persistencia y actualiza el Modelo de Lectura * Modelo de lectura: * Se encarga de las lecturas * Las trata como algo que debe estar fuera del modelo * La separación en el modelo causa un problema: Consistencia Eventual. El Modelo de Lectura es eventualmente consistente, es decir, hay un retraso entre la actualización del Modelo de Escritura y el Modelo de Lectura * Los procesos de actualización se llaman Write Model Projections. El proceso puede ser asíncrono o síncrono. * Implementamos los procesos de actualización a través de Eventos de Dominio * Event sourcing * Construye sobre CQRS * Nos permite tener una sola tabla que guardará todos los Eventos de Dominio * No precisa de ORM * Para mejorar la perf. emplea Snapshots de los agregados cada N eventos o cada N segundos. Otras herramientas de las que habla el libro son las siguientes: * Value Objects * Objetos cuya igualdad no está basada en su identidad sino en su contenido, i.e. Money o Date object. * Características * Mide, cuantifica o describe algo en el Dominio * Es inmutable * Es comparado mediante su valor * Es completamente reemplazable cuando la cuantía o la descripción cambia * No tiene efectos secundarios * Testing * Como cualquier otro objeto corriente * Testamos su inmutabilidad * Persistencia * Típicamente dentro de un agregado * Persistir como valor embebido o como LOB serializado * Entidades * Objetos con una identidad que permanece con el tiempo, i.e. Orden en un e-commerce * Utilizar un Value Object como identidad (son inmutables y pueden implementar comportamientos, hacen la operación de igualdad explícita) * Crean los Eventos de Dominio * Operación de identidad: cuatro opciones * Delegar al mecanismo de persistencia (AUTO_INCREMENT) * Obtenerla del cliente en los dominios en los que tenga sentido (libro y su ISBN) * Generarla en la aplicación (recomendado si no la obtenemos del cliente). Utilizar UUID. Construimos el Value Object en el Repositorio * Otro Contexto Delimitado genera la identidad * Testing * Testamos las invariantes porque el comportamiento estará creado alrededor de éstas * Servicios * Útiles cuando hay operaciones en las que la responsabilidad no caiga sobre Entidades o Value Objects * Tres tipos de servicios * Servicios de Aplicación * Son la capa intermedia entre los clientes y la lógica de dominio. Transforman comandos del exterior en operaciones dentro del dominio * Reciben y responden con DTOs * Servicios de Dominio * Se encargan de operaciones que no encajan bien en Entidades o Value Objects. Sólo manejan tipos del Dominio * Servicios de Infraestructura * Operaciones que solucionan problemas de infraestructura, por ejemplo, enviar emails * Eventos de Dominio * Eventos relacionados con cambios en el Dominio * Ayudan a comunicarnos con otros Contextos Delimitados * Mejoran la perf. forzándonos a tener Consistencia Eventual * Sirven como histórico * Representar como verbos en tiempo pasado * Contienen fecha del evento e identidades de Entidades relacionadas * Agregados * Son Entidades que están compuestas de otras Entidades y Value Objects para ayudar a mantener un estado consistente * Repositorios * Actúan como lugares de almacenamiento * Normalmente hay una relación 1:1 con los agregados * No son DAOs, representan Colecciones * Specification Pattern para las queries