That's the problem, business systems are not complex, they are incredibly simple, they are made complex by the way we think about and structure our models and then interact with them. We have the wrong boundaries, and the wrong languages

Would you be able to point me towards modelling approaches/boundaries/languages that would be more appropriate? I'd be interested to learn about better alternatives, as I don't yet see the big flaws in relational models

Datomic https://www.datomic.com/ a not-sql cloud database with a robust and principled information model competitive in use case with rdbms. In agreement with your parent, Datomic is very different and most commonly used from the Clojure programming language which rejects similarly much mainstream thought/practices. https://clojure.org/ https://clojure.org/about/state The talk Database as a Value https://www.infoq.com/presentations/Datomic-Database-Value/ is a good starting point to understand the flaws in relational model implementations (it has been argued on r/clojure that Datomic more faithfully implements relational algebra than RDBMS does – https://www.reddit.com/r/Clojure/comments/99f4ln/datomic_is_...)

Counter-intuitively Datomic is in violent agreement with /u/rqmedes where he said "A better alternative is having the data, data model and business logic tightly bound in one place. Not separated in multiple "tiers"" – Datomic inverts/unbundles the standard database architecture such that the cached database index values are distributed out and co-located with your application code such that database queries are amortized to local cost. Immutability in the database is how this is possible without sacrificing strong consistency, basically if git were a database you end up at Datomic.

Unfortunately there is no real alternatives, its like operating systems, one or two system have so much momentum that using anything else becomes extremely difficult even when they are inferior in certain domains. see http://www.fixup.fi/misc/usenix-login-2015/login_oct15_02_ka...

A better alternative is having the data, data model and business logic tightly bound in one place. Not separated in multiple "tiers"

When one of these things change it changes the rest.