Domain-Driven Design in PHP

Domain-Driven Design in PHP

Real examples written in PHP showcasing DDD Architectural Styles, Tactical Design, and Bounded Context Integration About This Book Focuses on practical code rather than theory Full of real-world examples that you can apply to your own projects Shows how to build PHP apps using DDD principles Who This Book Is For This book is for PHP developers who want to apply a DDD mindset to their code. You should have a good understanding of PHP and some knowledge of DDD. This book doesn't dwell on the theory, but instead gives you the code that you need. What You Will Learn Correctly design all design elements of Domain-Driven Design with PHP Learn all tactical patterns to achieve a fully worked-out Domain-Driven Design Apply hexagonal architecture within your application Integrate bounded contexts in your applications Use REST and Messaging approaches In Detail Domain-Driven Design (DDD) has arrived in the PHP community, but for all the talk, there is very little real code. Without being in a training session and with no PHP real examples, learning DDD can be challenging. This book changes all that. It details how to implement tactical DDD patterns and gives full examples of topics such as integrating Bounded Contexts with REST, and DDD messaging strategies. In this book, the authors show you, with tons of details and examples, how to properly design Entities, Value Objects, Services, Domain Events, Aggregates, Factories, Repositories, Services, and Application Services with PHP. They show how to apply Hexagonal Architecture within your application whether you use an open source framework or your own. Style and approach This highly practical book shows developers how to apply domain-driven design principles to PHP. It is full of solid code examples to work through.
Sign up to use

Reviews

Photo of Pedro Giménez
Pedro Giménez@pedro
4 stars
Aug 12, 2021

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

This book appears on the shelf Ddd

Domain-Driven Design Quickly
Domain-Driven Design Quickly by Floyd Marinescu
Implementing Domain-Driven Design
Implementing Domain-Driven Design by Vaughn Vernon
Patterns, Principles, and Practices of Domain-Driven Design
Patterns, Principles, and Practices of Domain-Driven Design ...

This book appears on the shelf Agile

Domain-Driven Design Quickly
Domain-Driven Design Quickly by Floyd Marinescu
Implementing Domain-Driven Design
Implementing Domain-Driven Design by Vaughn Vernon
The Lean Startup
The Lean Startup by Eric Ries
Succeeding with Agile
Succeeding with Agile by Mike Cohn
Patterns, Principles, and Practices of Domain-Driven Design
Patterns, Principles, and Practices of Domain-Driven Design ...