So, [last time](https://dev.to/barryosull/messy-event-flows-part-1) we looked at our event flow, and I went into detail about the problems we've had with it. The next step was to remodel our event flow, not as it is, but how it should be. As part of this exploration, I also annotated the event flows, being more precise on what's needed by each iteration of the flow to ensure constraints are met. Ie. Do we need to listen to all events, or just a subset, and if it's a subset, can we define it? # The updated model ![Event Flow/Temporal model](https://thepracticaldev.s3.amazonaws.com/i/t7z6n9z0uoggwz24d10j.png "Event Flow/Temporal mo...
Read on »
Blog Articles on DDD, Event Sourcing and software development in general, with a sprinkle of PHP and sarcasm.
# Intro I've been trying to write lately and I've been finding it difficult. Then I watched a video ["Don't create, document"](https://www.youtube.com/watch?v=RVKofRN1dyI). TL;DR: instead of trying to write a how-to, focussing on a solution, why not document what you're doing, as you work towards a solution? I really like this idea, as it's a problem first, solution second approach, which is how any process of discovery or creation should begin (true of coding and any other endeavour really). So without further ado, let's get into a problem we've been facing. # The current state of our system We have an [event sourced](https://mar...
Read on »