Data Oriented Programming in Java: Progress Update 2025-11-09

Published: 2025-11-09

Early Access here: Data Oriented Programming in Java

Available in MEAP: Chapters 1, 2, 3, 4, 5, 6, 7, 8
Pending reviews: Chapter 11
Currently working on: Revisions to chapter 9
Current Stats:

  • Words: 8823
  • Listings: 23
  • Figures Used: 20
  • Figures Made: 45

OK. Welp. So much for a short chapter. Scope creep occurred.

Left: how it started.
Right: How it's going

The big problem with the first draft was that I departed from my rule of only using examples from the real world. Instead, I made up some cockamamie example about a checkout flow in some imagined e-commerce site. The problems were all made up and dumb.

Luckily, I don't have to invent terrible e-commerce codebases – I work for Amazon![0] I'm drowning in terrible e-commerce codebases!

So, I started over and spent several nights just spelunking around the internals of Amazon's various retail codebases. You'd think there'd be just one, but there are tons. Some aren't even ours. Random left overs from an acquisition made years ago.

I eventually found this perfect goldilocks codebase with all the problems (and more!) that I wanted to talk about in this chapter. I spent the better part of a Saturday studying just one of its cart modification methods. It's now the example around which I base the chapter. There was a bug so subtle that I just had to include it as a challenge in the book.

With the new complexity comes a new direction. This is less a revision and more a rewrite at this point. Similarly, this new direction comes with a new chapter title (which Manning is never happy about). The two contenders are "Refactoring Towards Data" or "Drawing Boundaries with Data." Still deciding.

The original title, "maintaining integrity in the domain," is from a time when I thought I'd learn harder into functional patterns in the book. This chapter was going to be entirely about validation, and it was here that I would talk about stuff like Monads and Applicatives. But opinions change over the course of a book. Java developers, by and large, aren't interested in monadic stuff (this was advice Brian gave to me in our very first meeting.) The few that are don't need me to explain anything to them. What happens in practice is that Monads drive a wedge between Java developers. People who aren't interested in them never will be. Trying to force them just creates a schism in the codebase (Thus my changed opinion on this topic)

The chapter is now written loosely in the style of Martin Fowler's Refactoring book. The first half is devoted to identifying "smells" in the code. The second half is how to fix them.