Acceptance tests are core to any stable system, they're how you make sure it actually works, start to finish (My preference is to write them first, use them a guideline to make sure the feature I'm writing works as expected). When writing acceptance tests, it's best to treat the system as a [blackbox](http://softwaretestingfundamentals.com/acceptance-testing/), inputs go in and outputs go out, that's it. This proves our app works and can be interacted with by other systems. Some frameworks come with this built in, like [Laravel](https://laravel.com/), but not every app is written in those frameworks, infact most are not (especially...
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 »

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 »

Traits in PHP are a bit shite. At best they are an ineffective way to append functionality to a class, at worst they are an anti-pattern. They are often used as toggles for internal functionality (see Laravel's Acceptance tests) or as a lazy way to share common functions across a bunch of classes without using another pattern. # Why are they bad? ## Reading: They're hard to read. If you see that a class uses a trait, you have to open the trait to see what it's adding to the class. Usually the trait uses protected properties of the class, this means you have to flip between the trait and the parent class to figure out the type of...
Read more »