Data Oriented Programming in Java: Progress Update 2026-01-19

Published: 2026-01-19

Early Access here: Data Oriented Programming in Java

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

  • Words: 388
  • Listings: 0
  • Figures Used: 1
  • Figures Made: 1

Controversial take: Many Java developers have no idea how to design an application without Spring. This pops up all the time at Amazon. You hire someone with a decade of experience and then they spend their first few months struggling because they don't have their framework. For them, the framework was their architecture. Without it, they have no underlying philosophy of design. So, they flounder as they try to write Spring without Spring. Which, as far as I can tell, means adding the word "Service" to the end of every class name. Early code reviews involve a lot of "Ok, but how is this a service? Why do we need it? What does it do?"

A very similar problem happens with frontend developers. Certain frameworks, like React, become so ubiquitous that programmers become molded by them. Programming the "right" way becomes synonymous with programming the framework's way. If you take away the framework, you take away everything. Young me gave a talk on this problem way back in the day.

So, the theme of this chapter is developing a philosophy of architecture from first principles – something that can answer questions about how and where we draw boundaries and what properties we're trying to introduce by doing so.

As usual, I've spent the last few weeks stressing about the example I'll use to teach this topic. The outline is up to 4500 words, which doesn't bode well for the size of the chapter. I finally had a break through while reading Maurício Aniche book Simple Object Oriented design. I'll post a review of it separately, but I found several ideas in it tragically under developed in explaining the why behind architectural decisions. It made me realize that even the smallest toy example can be used to explain architectural principles which apply everywhere. If you really understand the why, there's no difference between small decisions and big ones.