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):

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.

If you’re developing applications in a Domain-Driven Design style and using Doctrine 2.5, you may be struggling with implementing your entities identities, I mean, UserId, ProductId, and so on. Embeddables are cool, but limited. Surrogates are not necessary anymore. Here are some short tips and examples about how to proceed.

Last friday, I did the MySQL 5.6 Developer Certification Beta Exam. This is the exam that Oracle is launching because of the new MySQL 5.6 Developer certification that will replace the old MySQL 5.0 certification in 2014. I don’t know if I’m certified yet because in beta, all candidate exams have to be reviewed in order to analyse how difficult it was, what questions were not appropriated, typos, etc.) before going live.