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

Published: 2026-01-27

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: 4944
  • Listings: 17
  • Figures Used: 2
  • Figures Made: 1
Chapter 10 is cruising along.

There is something I can't address in my book that I'll address here: good architecture fits the design of the code to the capabilities (and constraints) of your infrastructure.

This is heresy to suggest and completely different from what (almost) every architecture book will say.

Exhibit A: Uncle Bob's Clean Architecture. (emphasis mine)

[...] decisions about frameworks, databases, web servers, [...] and the like. A good system architecture is one in which decisions like these are rendered ancillary and deferrable. A good system architecture does not depend on those decisions. A good system architecture allows those decisions to be made at the latest possible moment, without significant impact.

That's bad system design. It ignores physics. An application designed around a high-throughput key/value store will be – must be – shaped fundamentally different from one built around, say, an RDBMS like postgresql. Of course, you could "abstract away" the details and design your application to be "portable" and agnostic and build around magical interfaces, but doing so would undermine the very reason you chose a particular piece of technology in the first place.

This is not saying that boundaries don't exist. It's saying that infrastructure and code an inexorably linked at the architectural level. Of course, in general your application should know as little about the database as possible. In general loose coupling is preferable to tight coupling. In general web servers don't matter.

Until they do.

Then all the generalities go out the window.

Progress: