Here are my notes from [DDD EU 2022](https://2022.dddeurope.com/schedule/). It was a great conference this year with a focus on models, growth, managing complexity and dealing with legacy. Will definitely review these notes in the near future and see how I can apply them to my work day to day. ## Opening Keynote Speakers: - Andrew Harmel-Law - Diana Montalion - Mike Rozinsky - Gayathri Thiyagarajan **The advice process:** 1. When working on something, get advice from two groups: 1. Those affected by the decision 2. Experts in the area 2. Then it's up to you to decide The goal is to free up decision bottlenecks from making deci...
Read more »

The following are my notes from the last DDD IE meetup, [6th June 2019](https://www.meetup.com/Domain-Driven-Design-Ireland/events/261668803/), on how to introduce DDD to your company. This post is about the concepts we discussed and discussions we had around the topic. There's some great stuff in here, the kind that can only happens through discussion and collaboration. First off, the meetup itself was structured as half talk, have group discussion, with discussion interspersed throughout the slides. We've done a few of these style of meetups in the past and they've worked out really well. Here are the slides: https://slides.com...
Read more »

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 »

I've been talking a lot about Domain Driven Design (DDD) lately, be it at meetups or with clients, so I thought I'd write down my thoughts and see if it helps. Now, lots of people have written about DDD from a technical perspective (see the end for links), so I'm not going to do that, instead I'm going to discuss DDD from a non-technical perspective. This is DDD for everyone else. ## Solutions Always Overrun Designing and building a solution is not a trivial problem. It never goes smoothly, and even if it's completed on time (which is never) the solution is usually ineffective and needs to be changed, often drastically. This lea...
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 »