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?

I don't think a db/domain model mess is inevitable. But I do think that it requires more discipline to avoid than most projects / organizations exhibit. Maybe I'm just burned by ORMs, they certainly don't help in that regard. I'm sure it's better with JOOQ 😄.

I don't think ORMs vs jOOQ are a problem here. Many ORMs (e.g. JPA, also others) embrace the relational model, and work best when the schema is normalised. Yes. A *lot* of discipline is needed. Normalisation is very hard to get right, and some tradeoff is inevitable.

But it almost always pays off in the long run. I love this comment on that topic: blog.jooq.org/2014/10/20/sto…

Relational databases and TNF are often dismissed or underused for bad reasons, and I applaud your advocacy for them. But if your main use cases are for a few variants of aggregated data, decomposing and then rejoining them, even with materialized views, creates unnecessary effort

I replied to a tweet that was making a generic claim, and throughout my tweets, I advocated for the best default, not a very specific case.