Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación.

En este vídeo, vamos a configurar Kibana para montar gráficos y ver la información de los eventos que hemos enviado a Elastic de una forma que negocio flipe :)

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación.

En este vídeo, vamos a ver la cómo enriquecer el evento de dominio antes de enviarlo a Elastic. Agregaremos información sobre la request, memoria, etc. para traquear si algún servidor está procesando menos eventos de un cierto tipo.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación. En este vídeo, vamos a ver la segunda alternativa para enviar todos los eventos juntos de una vez, después de ejecutar el command handler. Reducimos números de peticiones mejorando el rendimiento.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events pero esta vez con un caso práctico de uso muy interesante para marcarse un tanto con negocio. Vamos a enviar los eventos de dominio contra un Elastic para que podamos finalmente agregar un Kibana y tener métricas en tiempo real de lo que ocurre en nuestra aplicación. En este vídeo, vamos a ver una de las alternativas para hacer esto, el envío síncrono a Elastic por cada eventos disparado.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este sexto video de la serie, vamos a distribuir los eventos, que tenemos persistidos en base de datos, hacia un sistema de colas como RabbitMQ. Veremos algunas consideraciones y trucos a tener en cuenta.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este quinto video de la serie, vamos a empezar a discutir manera de distribuir los eventos. El primer método es quizá menos conocido, REST. Veremos qué beneficios tiene y algunos trucos para implementarlo.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este cuarto video, vamos a ver cómo implementar la persistencia de Eventos de Dominio, para qué es útil y cuáles son sus beneficios.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este tercer video, veremos la segunda alternativa para disparar un evento de dominio: un publisher estático. Veremos sus puntos fuertes y flojos.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Continuamos con la serie sobre Domain Events. En este segundo video, veremos la primera alternativa para disparar un evento de dominio: acumularlos en la entidad. Veremos sus puntos fuertes y flojos.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

Hola Amigos del Rigor! Arrancamos una miniserie de videos sobre Domain Events. En este primer video, veremos cómo modelar un evento de dominio e introduciremos las diferentes manera de dispararlos. En los siguientes, veremos en detalle dichas alternativas, así como su relación con la persistencia y la distribución.

He creado una lista de reproducción pública con los videos que vaya publicando. La podéis encontrar aquí. Si los videos os gustan, no olvidéis suscribiros a mi canal. Espero que os guste!

#MayTheRigorBeWithYou

tl;dr: Entity constructor should be called once in its entire life. That’s why good ORMs don’t use constructor to reconstitute objects from the database. Good ORMs use reflection, deserialization or proxies. So, fire your Domain Events in the constructor.

Last week, I saw a presentation about going from coupled-to-framework code to a Domain-Driven Design approach in a sample application. It was a good talk. However, in my honest opinion, there were some mistakes that are important to address. In order not to troll, I have checked with the speakers to write this post ;).

One of the mistakes, that I would like to point is where a Domain Event about “a new product was created” should be trigger specifically inside the Product Entity.

Speakers were showing a “Video” Entity with a named constructor called “create”. They were calling _new _inside the named constructor and then firing the event. I mean, the Domain Event was not fired inside of the real constructor. Let’s see the code we’re talking about (the whole repository can be found here):

Today, Keyvan, Christian and me are very happy to announce that “Domain-Driven Design in PHP” book is 100% complete. 380 pages and around 1400 readers so far.

Thanks

Thanks, thanks, thanks.

Thanks to everyone that has supported us in this project.

Thanks to Christian and Keyvan. We don’t need words to understand each other.

Thanks to our families and friends. Love is what you need to keep pushing.

Thanks to Edd Mann for helping at the beginning with the language implementation details ;).

Thanks to Matthias Noback for his suggestions and his foreword.

Thanks to Vaughn Vernon for being pragmatic and inspiring.

Thanks to Ricard Clau, Albert Casademont, Victor Guardiola and Jordi Abad for your contributions.

Thanks to Natalye Childress for non stopping asking about uppercase or lowercase. With your work, the book can be read.

Thanks to everyone that committed fixes, you are great: Jonathan Wondrusch, César Rodríguez, Yannick Voyer, Oriol González, Henry Snoek, Tom Jowitt, Sascha Schimke, Sven Herrmann, Daniel Abad, Luis Rovirosa, Luis Cordova, Raúl Ramos, Juan Maturana, Nil Portugués, Nikolay Zujev, Fernando Pradas, Raúl Araya, Neal Brooks, Hubert Béague, Aleksander Rekść, Sebastian Machuca, Nicolas Oelgart, and Marc Aube.

tl;dr: If you are sending messages to RabbitMQ to communicate one application to another, you are not doing Event Sourcing. You’re just doing messaging ;)

In the last two months, I’ve seen different nice talks using DDD, CQRS or Event Sourcing in the talk title. However, after watching the content, I think there are some general misunderstandings about some of the concepts. The most important one, in my honest opinion, is calling Event Sourcing to sending messaging to other applications using a broker. Event Sourcing is not about that. Let me explain a bit more.

Cuando desarrollamos una aplicación nueva, todo va muy rapidito. Hay poco tráfico, pocas queries y si hay alguna más “dura” usamos alguna cache como Memcached o Redis. Pero a medida que agregamos más funcionalidad a una página, el número de queries a base de datos u otras infraestructuras va creciendo. Hasta que sin saber cómo, haces 300 queries, y no es broma, en la ficha de algún producto.

El problema es que estamos acostumbrados a hacer muchas queries de lectura y muy pocas de escritura en estructuras bastante normalizadas. Eso escala mal en base a nueva funcionalidad. Un buen approach en busca del máximo rendimiento es la consistencia eventual, estructuras desnormalizadas y proyecciones.

Os dejo el video de la formación de @AtrapaloEng sobre cómo el uso de Eventos de Dominio y el uso de conceptos de CQRS nos pueden ayudar enormemente a mejorar el rendimiento de nuestras aplicaciones.

Cuando trabajamos con aplicaciones DDD-style (aunque para las otras también aplica), una de las preguntas clásicas es como ejecutar tareas relacionadas con infraestructura desde las zonas más internas como Value Object o Entidades, sin violar la dependencias hacia capas superiores e incluso el SRP. Un ejemplo es logar información como acciones de usuario (tipo intento de acceso al sistema, alta de usuario, baja de usuario, etc.). El pasado Viernes, orientamos la formación de @AtrapaloEng sobre este tema. Os dejo el video y los ejercicios. Formación práctica basada en el proyecto de LastWishes con múltiples ejercicios resueltos in live coding.

Siguiendo con la formación de DDD en Atrápalo, os dejo la sesión de formación sobre Domain Events y BC Integration. Que la disfrutéis.