We've discussed the [bones of projectors in the past](/blog/projection-building-blocks-what-you-ll-need-to-build-projections), this time let's go deeper and look at how to manage them. At it's simplest a projector is something that takes in a stream of events and does some work on them, projecting them into whatever shape or operation is needed. Like anything though, there's more to it than that, lots more. That's what this article is, my attempt to discuss the complications and problems you will run into while working with projectors day to day. # Run modes Let's start simple, let's talk about the different modes of projectors a...
Read more »

In the [last article](https://barryosull.com/blog/projection-building-blocks-what-you-ll-need-to-build-projections) we looked at projectors, the backbone of any CQRS/Event Driven system. This article was originally meant to be about implementing projectors, but I realised there was an important question to answer first, one that would shape the solution, "When do we project the events, now, or later?". Turns out this question has far reaching effects, so it's important we dig into it before moving onward. # Immediate vs Eventual Consistency When it comes to projectors there are two choices, immediate or eventual consistency. With i...
Read more »

Let’s talk about projections. This topic is quite large, so this is the first part in a four part series on projections. 1. **Projection Building Blocks**: What you'll need to build projections 1. **Broadcasting events in PHP**: Techniques and technologies 2. **Designing Projections**: How to design and implement real world projections 3. **Projection DevOps**: Continuously deploying new/updated projections with zero downtime If you've read my previous articles, you should have the basics of [event sourced](event-sourcing-what-it-is-and-why-its-awesome)/[event driven](https://dev.to/barryosull/event-granularity-modelling-even...
Read more »

Interested in building an event driven application? If so there's one problem that will rear it's head pretty early; how big or small do you make your events? # Event Driven Systems Before we begin, let's give some background on Event Driven Systems. Event Driven systems don't make synchronous calls to each other, instead they broadcast messages, ie. "Events". Other services listen for these events and process them at their own speed. Say a service starts to slow down or crashes, other services will keep working as if nothing is wrong. Once the failing service is booted up again, it goes back to processing events and catches up to ...
Read more »

There are two things I wish I knew when I started building Event Sourced Apps. 1. Always talk to the domain expert before building or designing anything, no matter how "simple" 2. Always start with events, don't start with a UI, no matter how "simple" it is When we ignore the above and just forge ahead, we invariably end up with CRUD based events. Nine times out of ten these events will not mirror the actual business processes, and instead they will get in the way and make development harder and slower. # The problem with CRUD [CRUD](https://en.wikipedia.org/wiki/Create,_read,_update_and_delete) stands for Create/Read/Update/Dele...
Read more »

A continuation on the [Messy Event Flows series](https://dev.to/barryosull/messy-event-flows-part-1) (if you could call it that). You don't need to read it first, but if you're interested, give it a shot, it gives a little more context. In the [last article](https://dev.to/barryosull/messy-event-flows-part-2---what-it-should-be) we talked about our domain wide (cross aggregate) constraints, and mentioned one way to implement them in an [event sourced system](https://dev.to/barryosull/event-sourcing-what-it-is-and-why-its-awesome), but we haven't gone into any real detail since then. So let's look at one of the constraints and fi...
Read more »

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 more »

# 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 more »