Live Coding Journal - Mar 23, 2026

Notes from Today’s Live Coding Session

I’m back from my break! I was at DevNexus in Atlanta, where I gave a talk on automated refactorings in IntelliJ IDEA. Last week I attended the always awesome JavaOne conference a few miles down the road in Redwood Shores, California. I mentioned a few of the talks that I encourage folks to watch out for when they appear on YouTube.

Consistency Boundaries

After getting back into the JitterTicket codebase (and upgrading to the newly released JDK 26), I continued my thought process around Aggregates in event-sourcing vs. DCB (Dynamic Consistency Boundaries). I’ve decided to use the term “Command Consistency Boundaries” instead of DCB, because the boundary isn’t all that dynamic, it is based on the needs of each command. (See around 41:00 in the video.) This comes into play with the validation I’m adding for the Scheduling Concert. There are generally three kinds of validations/rules that are evaluated when deciding to execute a command:

1. Parameter validation: are the parameters in range (parse 'em into Value Objects to make sure!) and internally consistent (across multiple parameters, such as City+State+Postal Code matching)
2. Internal validation: often these are the Domain Rules that use the state of the entity, e.g., does the Concert have sufficient tickets available to fulfill the number of tickets being purchased?
3. External validation: requires information from outside of the entity, possibly even outside of the process (system), e.g., is this email address unique, does this concert date conflict with one already scheduled, or does this user have authorization to take this action in the first place?

What I find so interesting about the CCB (command-consistency boundary) is that we can gather precisely (no more, no less) the inputs required for all these decisions to be made, instead of loading more information than we might need (via an Aggregate) and then, separately, getting the external information (e.g., query a database for email addresses). (See around 2:50:00 in the video.)

Heuristics for Missing Events

I came up with a couple of heuristics that might indicate missing events. One is if a projection requires access to the current date or other out-of-process information that’s not in any event. An example here (around 1:35 in the video) is discarding concerts that already took place in the past when projecting Scheduled Concerts (to be used when looking for scheduling conflicts). In this case, I’m missing a ConcertCompleted event that would drop the concert from the projection of scheduled concerts. After all, there’s no need to look for conflicts when scheduling a new concert against concerts that happened in the past, since you can’t schedule a new concert in the past!

The second is if you find the projection having unbound growth, mainly that nothing ever gets deleted/removed from the projection. This is a weaker heuristic, because for things like Customer Emails, it will obviously grow as long as your adding more customers. However, there will be customers who close their accounts or change their emails, so if you’re not removing emails from the projection, you might be missing a CustomerEmailChanged or CustomerAccountClosed.

Event Serialization (Encoding)

In our book club, we’re reading Designing Data-Intensive Applications, and we just finished the chapter that explored different ways of serializing (encoding) in-memory data structures to disk. I had done some profiling on JitterTicket and found that a fair amount of time is being spent on decoding the JSON to Event objects, so I’m going to try encoding the event using Avro to see how much of a difference it makes.

Next Steps

We’ll implement the external validation for scheduling concerts and then work on Avro encoding for event payloads.

Join me on my next stream, which I usually do Monday through Thursday, starting at 19:00 UTC on Twitch: https://jitterted.stream.