"Talk to your customers" is great advice. But waiting for consensus is a trap.
https://nathanlively.substack.com/p/the-consensus-traphtml?r=hhqf8
https://nathanlively.substack.com/p/the-consensus-traphtml?r=hhqf8
Substack
The Consensus Trap
You want your app to be a hit.
Most Event Modeling examples out there show the classic "Post-Redirect-Get" UI loop. But what happens when your app doesn't have a UI? 🤔
Lately, I've been using Event Modeling for complex middleware applications. Instead of user clicks, my boards are driven entirely by Translators and Automations reacting to third-party APIs.
Take a standard integration: System A creates a contact, and we need to mirror that in System C via our middleware (System B). Here is how I map that flow:
1️⃣ System A emits a "Contact Created" external event.
2️⃣ System B’s Translator catches it and issues a "Create Contact" command.
3️⃣ System B records its own "Contact Created" domain event.
4️⃣ A Read Model queues up "Contacts To Create."
5️⃣ An Automation reads the queue and triggers the target "Contact Created" event in System C.
#EventModeling
Lately, I've been using Event Modeling for complex middleware applications. Instead of user clicks, my boards are driven entirely by Translators and Automations reacting to third-party APIs.
Take a standard integration: System A creates a contact, and we need to mirror that in System C via our middleware (System B). Here is how I map that flow:
1️⃣ System A emits a "Contact Created" external event.
2️⃣ System B’s Translator catches it and issues a "Create Contact" command.
3️⃣ System B records its own "Contact Created" domain event.
4️⃣ A Read Model queues up "Contacts To Create."
5️⃣ An Automation reads the queue and triggers the target "Contact Created" event in System C.
#EventModeling
I realized recently (from Ted Young) that I wasn't actually doing event sourcing in ShowBook. I was just doing CRUD with an audit trail.
My initial, naive implementation was to create a command and an event for every single field in my domain. Basically, I was just replicating the getters and setters of a POJO.
Ted pointed out a crucial missing piece: Commands and Events shouldn't just record data changes; they need to represent real business concepts and intent.
For example, if you just have CRUD-style `UpdateStartTime` and `UpdateEndTime` commands, it's hard to enforce chronological rules. But if you shift to capturing intent—like a `RescheduleItem` command that takes both times at once—the domain has all the context it needs to enforce that business rule before emitting an `ItemRescheduled` event.
Move from modeling technical needs to business needs.
My initial, naive implementation was to create a command and an event for every single field in my domain. Basically, I was just replicating the getters and setters of a POJO.
Ted pointed out a crucial missing piece: Commands and Events shouldn't just record data changes; they need to represent real business concepts and intent.
For example, if you just have CRUD-style `UpdateStartTime` and `UpdateEndTime` commands, it's hard to enforce chronological rules. But if you shift to capturing intent—like a `RescheduleItem` command that takes both times at once—the domain has all the context it needs to enforce that business rule before emitting an `ItemRescheduled` event.
Move from modeling technical needs to business needs.
Last week, I needed to make a "small" change to the way contacts are handled in ShowBook. It ended up taking all day, touched 99 files, and was a massive pain.
Because I was using a single `ShowBook` aggregate in my domain model, every change rippled. My projectors relied on it, my deciders relied on it, my UI relied on it. If I touched the domain, I broke the world. I thought this minor pain was just the inevitable "trade-off" of good DDD.
But I've been reading Martin Dilger's book Understanding Event Sourcing, and it made me realize there might be a better way: Vertical Slice Architecture (VSA).
To deal with the pain of my 99-file refactor, I decided to do a rewrite. And I'm surprisingly pleased so far.
I completely deleted my aggregate. It doesn't exist anymore.
Instead, I'm building tiny vertical slices. I have one slice just for "Renaming the ShowBook", and another just for "Rescheduling the Event Dates."
Because I'm using Event Sourcing, I realized I don't actually need a centralized Domain object to enforce rules. When a command comes in, my backend just folds the event history into the exact, tiny shape it needs to make a decision, emits a new event, and throws the state away.
This also changed my UI. I was chatting with Claude Code about how to build the front-end for this, and it suggested micro-pages. Instead of a giant form trying to manage an entire ShowBook, I now have small, focused forms that map 1:1 with my backend slices.
It's so much easier to reason about. I open a slice, I see a few fields, a specific command, a pure-function decider, and a local read model. If I need to change how dates work, my contacts remain completely untouched.
I'm still learning the ropes, but deleting my God Aggregate and moving to Task-Based UIs and VSA has made adding features easier.
Has anyone else made the jump from Hexagonal to Vertical Slices or somewhere in between?
Because I was using a single `ShowBook` aggregate in my domain model, every change rippled. My projectors relied on it, my deciders relied on it, my UI relied on it. If I touched the domain, I broke the world. I thought this minor pain was just the inevitable "trade-off" of good DDD.
But I've been reading Martin Dilger's book Understanding Event Sourcing, and it made me realize there might be a better way: Vertical Slice Architecture (VSA).
To deal with the pain of my 99-file refactor, I decided to do a rewrite. And I'm surprisingly pleased so far.
I completely deleted my aggregate. It doesn't exist anymore.
Instead, I'm building tiny vertical slices. I have one slice just for "Renaming the ShowBook", and another just for "Rescheduling the Event Dates."
Because I'm using Event Sourcing, I realized I don't actually need a centralized Domain object to enforce rules. When a command comes in, my backend just folds the event history into the exact, tiny shape it needs to make a decision, emits a new event, and throws the state away.
This also changed my UI. I was chatting with Claude Code about how to build the front-end for this, and it suggested micro-pages. Instead of a giant form trying to manage an entire ShowBook, I now have small, focused forms that map 1:1 with my backend slices.
It's so much easier to reason about. I open a slice, I see a few fields, a specific command, a pure-function decider, and a local read model. If I need to change how dates work, my contacts remain completely untouched.
I'm still learning the ropes, but deleting my God Aggregate and moving to Task-Based UIs and VSA has made adding features easier.
Has anyone else made the jump from Hexagonal to Vertical Slices or somewhere in between?
Here is my new anti-AI/Nathan-slop process for adding features to ShowBook:
1. Create a new "chapter" in the event model.
2. Put in the final UI screen I know I want to end up with (e.g., the final data grid with all 20 fields).
3. Put in the initial starting screen (e.g., the upload form).
4. Work step-by-step backwards from that final screen, writing Java records for exactly what data is needed to hydrate that view, and figuring out what previous step supplies it.
5. Feed the draft model, plus example inputs and outputs, into an LLM and ask it to "grill me" to find missing continuity or data gaps. Found Pocock's grill-with-docs skill useful.
Doing this in a visual event model is cheaper than trying to figure it out in code.
If I had done this in code, I would have missed a mapping step, had to change a bunch of method signatures, deployed it, found a bug, and started over. Modeling first (hopefully) breaks that cycle.
1. Create a new "chapter" in the event model.
2. Put in the final UI screen I know I want to end up with (e.g., the final data grid with all 20 fields).
3. Put in the initial starting screen (e.g., the upload form).
4. Work step-by-step backwards from that final screen, writing Java records for exactly what data is needed to hydrate that view, and figuring out what previous step supplies it.
5. Feed the draft model, plus example inputs and outputs, into an LLM and ask it to "grill me" to find missing continuity or data gaps. Found Pocock's grill-with-docs skill useful.
Doing this in a visual event model is cheaper than trying to figure it out in code.
If I had done this in code, I would have missed a mapping step, had to change a bunch of method signatures, deployed it, found a bug, and started over. Modeling first (hopefully) breaks that cycle.
Event sourcing without Axon or Spring Modulith -- here's what "just enough" looks like in Spring Boot. 👇
Write slices follow a simple 4-step pattern inside SliceCommandProcessor:
1️⃣ Load the stream-filtered history from a GigaMap in EclipseStore.
2️⃣ Fold history → state with a pure `evolve` function.
3️⃣ Pass state + command to a pure `decide` function that returns new events.
4️⃣ Append with Dynamic Consistency Boundary optimistic locking
Read slices are just standard `@EventListener` methods. When a write slice appends events, `ApplicationEventPublisher` fires them synchronously.
Write slices follow a simple 4-step pattern inside SliceCommandProcessor:
1️⃣ Load the stream-filtered history from a GigaMap in EclipseStore.
2️⃣ Fold history → state with a pure `evolve` function.
3️⃣ Pass state + command to a pure `decide` function that returns new events.
4️⃣ Append with Dynamic Consistency Boundary optimistic locking
Read slices are just standard `@EventListener` methods. When a write slice appends events, `ApplicationEventPublisher` fires them synchronously.
What exactly is a production schedule?
aka show book, production bible, day sheet, master timeline
In the event production world, I'd define it as the master operational document that coordinates your entire crew. Unlike a minute-by-minute show flow or script, a production schedule provides a coarse-level overview of the entire event--typically organized by day → room → time → activity.
It captures the macro-level tasks, equipment needs, and room configurations, giving your team the exact situational awareness they need without getting bogged down in individual agenda items or speaker cues. Ultimately, it's the canonical artifact that turns a chaotic multi-room event into a smooth show. 🛠️📋
aka show book, production bible, day sheet, master timeline
In the event production world, I'd define it as the master operational document that coordinates your entire crew. Unlike a minute-by-minute show flow or script, a production schedule provides a coarse-level overview of the entire event--typically organized by day → room → time → activity.
It captures the macro-level tasks, equipment needs, and room configurations, giving your team the exact situational awareness they need without getting bogged down in individual agenda items or speaker cues. Ultimately, it's the canonical artifact that turns a chaotic multi-room event into a smooth show. 🛠️📋
Most production schedules are missing 3 columns.
- Activity Phase (Setup / Show / Strike) - Filter and scan at a glance.
- Technician (by name) - Everyone knows who owns what.
- Technical Needs - Not a full pull sheet. Just the outliers: "2 Meeting Owls, hybrid webinar setup." Enough to flag surprises.
Most include date, room, start/end times. Those are table stakes.
A production schedule (show book) isn't a calendar. It's a coordination tool. The columns you include help your team walk in confident instead of scrambling.
What column are most important to you?
- Activity Phase (Setup / Show / Strike) - Filter and scan at a glance.
- Technician (by name) - Everyone knows who owns what.
- Technical Needs - Not a full pull sheet. Just the outliers: "2 Meeting Owls, hybrid webinar setup." Enough to flag surprises.
Most include date, room, start/end times. Those are table stakes.
A production schedule (show book) isn't a calendar. It's a coordination tool. The columns you include help your team walk in confident instead of scrambling.
What column are most important to you?
What if you sorted your production schedule by Day → Room → Time instead of Day → Time?
You'd get something interesting.
Instead of a show book where Room 1 and Room 3 and the Ballroom are all interleaved by clock... each room gets its own block.
The manager still sees everything. The tech sees their room.
What do you think?
You'd get something interesting.
Instead of a show book where Room 1 and Room 3 and the Ballroom are all interleaved by clock... each room gets its own block.
The manager still sees everything. The tech sees their room.
What do you think?
A production schedule that says "AV Tech" isn't a schedule for anyone.
The moment you swap job titles for actual names - not "Sound Tech," but "Alex" - something shifts:
- Ownership kicks in. People show up differently when their name is in the document.
- Accountability is automatic. When the hybrid setup wasn't done, you don't ask who was responsible. You already know.
- The schedule becomes personal. Filter by name and a 50-row show collapses to the 11 rows that are actually Marcus's today.
The moment you swap job titles for actual names - not "Sound Tech," but "Alex" - something shifts:
- Ownership kicks in. People show up differently when their name is in the document.
- Accountability is automatic. When the hybrid setup wasn't done, you don't ask who was responsible. You already know.
- The schedule becomes personal. Filter by name and a 50-row show collapses to the 11 rows that are actually Marcus's today.
The production schedule isn't a pull sheet.
That lives in your Lassos, Flexes, and Current RMSes.
But, a production schedule can help highlight outliers and serve as a quick reference. As a sound tech, I'd prefer to see "8 lavs, 2 handhelds" than need to find the pullsheet and count up the inventory.
How are you handling this in your show book?
That lives in your Lassos, Flexes, and Current RMSes.
But, a production schedule can help highlight outliers and serve as a quick reference. As a sound tech, I'd prefer to see "8 lavs, 2 handhelds" than need to find the pullsheet and count up the inventory.
How are you handling this in your show book?
Six months before show day, your client mentioned her CEO always walks on to "Girl on Fire."
It came up once. Near the end of a 40-minute call.
You put it in the production schedule.
On show day: right song, right moment. She didn't even have to remind you. Nailed it.
A show book is not just a coordination tool for crew - it's a promise-keeping system for clients.
Walk-on music. Presenter mic preferences. "Our speaker hates lavalieres." The specific thing mentioned once, months out, that would otherwise vanish into email threads and half-remembered notes.
A script with cues might be more appropriate, but if there's only one cue, just note it in the show book.
What's the smallest client detail you've ever caught in a schedule that made a real difference on show day?
It came up once. Near the end of a 40-minute call.
You put it in the production schedule.
On show day: right song, right moment. She didn't even have to remind you. Nailed it.
A show book is not just a coordination tool for crew - it's a promise-keeping system for clients.
Walk-on music. Presenter mic preferences. "Our speaker hates lavalieres." The specific thing mentioned once, months out, that would otherwise vanish into email threads and half-remembered notes.
A script with cues might be more appropriate, but if there's only one cue, just note it in the show book.
What's the smallest client detail you've ever caught in a schedule that made a real difference on show day?
Do you have a Launchpad?
My friend Dave is looking for beta testers for his new app that turns your Launchpad into an audio meter. Contact him through the website -> https://hardwarevu.com/
https://hardwarevu.com/
My friend Dave is looking for beta testers for his new app that turns your Launchpad into an audio meter. Contact him through the website -> https://hardwarevu.com/
https://hardwarevu.com/
Hardwarevu
Hardware VU — Download & Setup
A small, free tool that turns a grid controller you already own into a VU meter. Made by 60 Works.
> "The scary part is that I might lose some of this information."
A multi-day, multi-room conference gets scheduled months out - across dozens of meetings and emails.
Somewhere in client meeting #9 of 14, the keynote speaker mentions needing a headworn mic and wanting to walk out to "Happy."
The mic made it onto the pull sheet. Then got swapped for a lavalier during packing. No one downloaded the music.
Six months later, the keynote speaker arrives at the event.
She has everything she asked for.
How?
The A1 reviewed the production schedule that morning. Noticed the requirements. Noticed they weren't staged. Called the shop for a rush delivery and tethered to his phone to pull the track.
Chris Shelton has been producing events like this for years. He puts it simply:
"Companies that hang with the details are remembered."
What's the smallest detail you've ever tracked in a production schedule that brought a client back the following year?
A multi-day, multi-room conference gets scheduled months out - across dozens of meetings and emails.
Somewhere in client meeting #9 of 14, the keynote speaker mentions needing a headworn mic and wanting to walk out to "Happy."
The mic made it onto the pull sheet. Then got swapped for a lavalier during packing. No one downloaded the music.
Six months later, the keynote speaker arrives at the event.
She has everything she asked for.
How?
The A1 reviewed the production schedule that morning. Noticed the requirements. Noticed they weren't staged. Called the shop for a rush delivery and tethered to his phone to pull the track.
Chris Shelton has been producing events like this for years. He puts it simply:
"Companies that hang with the details are remembered."
What's the smallest detail you've ever tracked in a production schedule that brought a client back the following year?
Sound Design Live
> "The scary part is that I might lose some of this information." A multi-day, multi-room conference gets scheduled months out - across dozens of meetings and emails. Somewhere in client meeting #9 of 14, the keynote speaker mentions needing a headworn mic…
"
The mic made it onto the pull sheet. Then got swapped for a lavalier during packing. No one downloaded the music.
Six months later, the keynote speaker arrives at the event.
She has everything she asked for.
How?
The A1 reviewed the production schedule that morning. Noticed the requirements.
The mic made it onto the pull sheet. Then got swapped for a lavalier during packing. No one downloaded the music.
Six months later, the keynote speaker arrives at the event.
She has everything she asked for.
How?
The A1 reviewed the production schedule that morning. Noticed the requirements.
Sound Design Live
> "The scary part is that I might lose some of this information." A multi-day, multi-room conference gets scheduled months out - across dozens of meetings and emails. Somewhere in client meeting #9 of 14, the keynote speaker mentions needing a headworn mic…
Noticed they weren't staged. Called the shop for a rush delivery and tethered to his phone to pull the track.
Chris Shelton has been producing events like this for years. He puts it simply:
"Companies that hang with the details are remembered.
Chris Shelton has been producing events like this for years. He puts it simply:
"Companies that hang with the details are remembered.
Sound Design Live
> "The scary part is that I might lose some of this information." A multi-day, multi-room conference gets scheduled months out - across dozens of meetings and emails. Somewhere in client meeting #9 of 14, the keynote speaker mentions needing a headworn mic…
"
What's the smallest detail you've ever tracked in a production schedule that brought a client back the following year?
What's the smallest detail you've ever tracked in a production schedule that brought a client back the following year?
Most production schedules treat the "Technical Needs" column like a dumping ground.
When a project manager dumps an entire warehouse pull sheet into a single spreadsheet cell, the onsite crew stops reading it. Chaos follows at 7:00 AM.
A production schedule isn't an inventory list - it's a coordination tool. Its job is to preserve high-level situational awareness, not document every cable in the truck.
So trim that column to the outliers. Flag only what's unusual about this specific room, session, or client:
- Slide notes on confidence monitor
- Presenter prefers a HH mic
That flag is what saves the show day.
When you run complex, multi-room corporate events, your show book dictates whether your team walks in calm or scrambling.
AV Owners & PMs: What's the one hyper-specific column you added to your scheduling grid that you now refuse to look at a show book without?
When a project manager dumps an entire warehouse pull sheet into a single spreadsheet cell, the onsite crew stops reading it. Chaos follows at 7:00 AM.
A production schedule isn't an inventory list - it's a coordination tool. Its job is to preserve high-level situational awareness, not document every cable in the truck.
So trim that column to the outliers. Flag only what's unusual about this specific room, session, or client:
- Slide notes on confidence monitor
- Presenter prefers a HH mic
That flag is what saves the show day.
When you run complex, multi-room corporate events, your show book dictates whether your team walks in calm or scrambling.
AV Owners & PMs: What's the one hyper-specific column you added to your scheduling grid that you now refuse to look at a show book without?