And I struggle to think of a clean line where you can actually separate those concerns. How are they different? How is the relational model not just your domain model? What would be some specific examples of where such a mess is inevitable?

It already starts with an applications usually joining the same set of tables at runtime to provide answers to business question. Separate tables provide alleged flexibility that is not only mostly not needed but imposes nothing but technical complexity.

Write a view for those joins. Or better. Write a function that composes your jOOQ joins dynamically for greater re-use.

If I can create an Order class that holds a list of LineItems and I can impose a minimum order amount rule over that list, I can write a unit test for that that needs nothing but Java and a ms to execute. Why should I complicate that?

Well, are you going to store it or not? If not, as you so eloquently put: en.wikipedia.org/wiki/Straw_…

Yes. But thats my point: why would you conflate the two? You argued separation of concerns yourself, didn’t you? You asked for a reason why one’d not use the relation model as primary. One answer: because it’s simpler to use a different one, not tied to a storage technology.

Admittedly, you could argue it would be even better to specify everything in a meta language, e.g. some kind of DSL, so that you’re not tied to Java

Sure, if you’re in a context where building DSLs is (economically) feasible. For mere mortals, it boils down to some arbitrary, general purpose programming language.

I’m not seriously suggesting that. I’m merely pointing out that you see no problem with a dependency on Java/the JVM, but do with one on SQL/an RDBMS.

I am surprised you actually derive *that* from the tweet. It was not my point at all.