Recently I've been thinking about folder structures, specifically how we structure our web apps to encourage the design we want and to enable other developers to explore and understand the codebase. This train of thought was spurred by a problem we faced with one of our apps, which I'll go into shortly. ## Folders Give Context When we open up an application the folder structure is the first thing we see, even before we glance down at the readme. It conveys the hierarchy of concepts and hopefully how they relate to each other. A haphazard folder hurts more than it helps, especially if you have to hop around from folder to folder. Ch...
Read more »

Do you work with Legacy code? You probably do and don't realise it. IMO, if the code is over 5 years old, messy and it makes money, then it's probably legacy. Legacy code is tricky, and most of us try to avoid it, moving onto sexy new ideas and projects as time moves on. This means that we never learn to deal with legacy, and all the while, the codebase is chugging along, getting worse and increasingly expensive to change. If we don't learn to deal with legacy code, then we'll never learn how to maintain systems over time. We need to address this. That's where this article comes in, it is a collection of my notes from reading and 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 »

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 »

At the last [PHPDublin meetup](https://www.meetup.com/PHP-Dublin/events/242463770/) I was asked "What do you do?" and as usual the answer boiled down to "I design and build event sourced applications". Which leads to the following question. "What is Event Sourcing?". That's where this article came from, it is my best shot at explaining Event Sourcing and all the benefits it brings. # The Status Quo Before we get into the nitty gritty of event sourcing, let's talk about the status quo of web development. At it's heart, current web dev is database driven. When we design web apps, we immediately translate the specs into concepts fro...
Read more »

Let's talk software architecture. Most of us know [MVC](https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller), it's the foundation for pretty much every web framework. As your product grows though, problems with MVC will start to appear. Even a relatively simple product can end up with a bloated and messy codebase. MVC is where we start, but what do you do when you need to evolve past it? Before we go further, let's examine why we have so much trouble explaining the answer. Here's a common conversation (for developers anyway) - devA: "Our codebase is really messy, how do we clean it up?" - devB: "We need to refacto...
Read more »

Below is a collection of notes I made after reading [Growing Object Oriented Software, Guided by Tests](http://www.growing-object-oriented-software.com/). I highly recommend that developers read this book. Writing tests is hard, and using tests to write good code is even harder. It takes a lot of time and a lot of getting it wrong before you can get it right. Well, the book above explains how to do it step by step, I'm definitely a better developer for having read it. Many thanks to the code wizard that lent it to me, you know who you are. I'm posting these notes online because it's a useful reference for myself, and hopefully o...
Read more »