Below you will find pages that utilize the taxonomy term “constructor”
Firing Domain Events in the __constructor
After my post about “Good ORMs do not call __construct a.k.a. where to fire my Domain Events”, nice discussions (and trolling) are happening in the Barcelona Engineering Slack Channel. Thanks to everyone for the feedback, ideas and concerns. You are more than welcome! The main concerns are:
- How do I fetch an Entity from ElasticSearch, using new and without firing the Event?
- How do I create stubs on the Entity that is firing the Domain Event?
- What are pros and cons of firing the Domain Event in the __constructor or in the named constructor?
So, I’ll take the original code as a starting point, and I’ll suggest different strategies to answer those questions.
Good ORMs do not call __construct a.k.a. where to fire my Domain Events
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):