The Only Agile Meetings You Need

Some places “do agile” because it’s the cool trendy thing that tech companies do nowadays. Their teams are usually mandated to do Scrum, which they take to mean two-week cycles with 2-3 hours of stand-up meetings, maybe 4 hours of refinement, 1-2 hours retro, another hour of sprint planning, another to demo, another higher-level roadmap meeting. That’s 10 hours of meetings even before you include all the ones you “took offline”.

Read More

CQRS: What and Why?

CQRS is really simple. Sometimes the idea gets conflated with other concepts such as Event Sourcing and DDD, but that is not CQRS. So, what is it then?

Read More

The Building Blocks of Domain-Driven Design

When learning DDD, it’s easy for us engineers to get caught up in all the technical jargon: “Aggregate Roots”, “Domain Events”, etc. Fundamentally though, Domain-Driven design is not about the technical details; it’s about creating a model and language that the business experts share with the technical experts (the software engineers). It is, perhaps ironically, about not using technical jargon.

Read More

Well-Crafted Software

Great engineers truly care about what it is they’re building. Not just the end result, making a customer happy and getting paid. They enjoy the engineering process, they love the tools they use, and they get a kick out of the job itself.

Read More

Visualising Software in Shapes

When I think of a software system, I see shapes and lines connecting groups of smaller shapes and smaller lines. Like a galaxy of solar systems with planets of continents, each with roads connecting cities with villages and hamlets. It’s a structure that fits related concepts together and hides away complexity at different scales.

Read More

Domain Events vs Integration Events

There are different kinds of events found in event-driven systems. They often represent the same thing that has happened, but serve different purposes and have different advantages. Here I’d like to outline the differences between a few terms.

Read More

Look, No Controllers

Those that have worked with me will know I’m a big advocate for Aspect-Oriented Programming. I generally like to “bolt on” concerns that sit outside of the main logic using the decorator pattern or some kind of behaviour that can wrap around a class or method, which follows the Open/Closed principle.

Read More

Software is about Drawing Boxes

That’s what it all comes down to. Not to diminish anyone’s long, hardworking career, but every design decision we make ultimately boils down to where we want to define a certain boundary. What concepts should we couple together? Which layers “know of” which? It’s all a structure of how thoughts and ideas fit together.

Read More

Domain-Driven Boundaries

At its core, Domain-Driven Design is about building shared models as a collaboration between domain experts and technical experts. When engineers speak the same language as the rest of the business, we can build an architecture that aligns with how the business works.

Read More

Introducing Reflectious

Whilst developing Firestorm, I noticed I was often combining Expression Trees with Reflection code. I’d find a static LINQ method, pass it a lambda expression argument and throw the whole thing into Expression.Call.

Read More

Why Firestorm?

Firestorm is a little thing I was working on that turned into a bigger thing I’m still working on a year later. As it grew, it spawned another little thing that’ll probably turn into a bigger thing too. Rinse and repeat. Sound familiar?

Read More