Why are we so often making the database the foundation of our architecture and not the domain logic? Because we feel more comfortable with the database than with the domain logic. We need to leave the comfort zone!

The relational model along with normalisation principles is a very robust way to model your domain. If you do it right, all your logic will just fall into place. You want to leave this "comfort zone"? Why? Are you sure you were doing it right in the first place?

That may be possible and even desirable for some domains. But I struggle to think of a project in my experience that did not end up as a mess of database concerns mixed with domain concerns when we used the database model as the domain model.

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.