# What is a DSL DSL stands for Domain Specific language, this means that it is a language that is designed to solve a specific problem in a domain. DSLs are great if you want to write a generic solution to a specific problem without all the boilerplate code. A good DSL is easy to write and understand. Once someone understands the domain language, they can read the DSL, and understand the problem, even if they're not a coder. DSLs allow us to automate many things, including aspects of development, greatly increasing our speed and lowering codes and error rates. # Here's one I made earlier At work, I was getting annoyed with how it a...
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 »

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 »