Talk in English - US at PolderPHP - Second Edition
Short URL: https://joind.in/talk/79ffd
(QR-Code (opens in new window))
Future Is A Thing Of The Past
Comments
Comments are closed.
I had a feeling something was off in your talk, but couldn't figure it out on the spot. However in the car on my way to home, i figured it out.
You do the following:
class product
function add($name) {
$this->name = $name;
$this->recordEvent(new ProductWasADded($name));
}
function replay($event)
if $event instanceof X ) applyEventCode() // does $this->name again;
Your domain shouldn't keep track of the states, the combined events should, or projections.
But you are updating your domain model with state through $this->name = $name;
The code actually should be:
function add($name){
$this->recordEvent(new ProductWasAdded($name);
}
function replay($events)
{
$this->events = $events;
}
And with your projection, you actually pick up the $productProjection->name.
This removes your if tree complexity. But introduces eventual consistency, which is probably the main reason you do the state updates in the first place.
However, the talk was a little bit chaotic, but oke
Mitchell, for a first time: Not too bad!
I think you got the message across, which is of course the most important goal of a talk, so i'd say: success! Also, i enjoyed it.
Some pointers that might be helpful:
*Good*
- You are very in sync with your slides, you seem to know 'em in & out. Good prep.
- The slides were good, usually projecting 1 message/subject.
- You don't take yourself too seriously and are easy to listen to.
*Improvements*
- Talk slower :) Just as you don't want too much information in 1 slide, you probably want to limit the number of words in a minute :) Take your time, don't fear pauses. I think you will feel better yourself as well :)
- As we discussed afterwards: It might be good to integrate in your talk why and when event sourcing is a very suited solution.
- At some points it felt like you were repeating yourself. Perhaps some slides overlap a bit. Also, this was probably the reason that it felt a little bit incoherent, as you noticed yoursellf. Perhaps it would be good to revisit all the aspects of the story and see if you can restructure them a bit.
With some of these improvements, i think you could make this a 5-star talk!
Your talk was not perfect, but still really enjoyable to me, it served well as an introduction to a cool way of doing event sourcing.
What I especially like was your clean code examples, and also the language used in them. No surprise that you mentioned DDD, as it shows in the lack of jargon in the naming you use in your code. E.g. $this->recordThat(new SomethingHappened()) just reads beautifully.
Another thing that your talk has going for it is the enthusiasm with which you deliver it. It is clear that you find this stuff really cool (and it is!) and it is fun that you show it so much. This is also a potential pitfall, because it makes you talk really fast and sometimes unintelligible. But, you already mentioned that yourself a few times, so I guess you are aware of it ;-)
One thing that could be better is some anecdotes of how you actually use event sourcing. I understand that the stuff that you used it in is still under wraps, but there must be some things that you can share without giving too much away. This would really add to your street cred. Plus, you are going to be asked this question every time you give this talk anyway, so why not come prepared with a few slides on how you've used it.
So, keep giving and improving this talk, and I will definitely come see your next one!
I will finish with a few friendly tips: dedicated event stores are a thing (geteventstore.com), as is the object-relational impedance mismatch (I find avoiding that last one a huge reason to use event sourcing).