I believe the easiest way to think about it is to get away from your programming tools and to start modeling your problem domain as tables in excel.
Once you have a relational schema that the business can look at and understand, then you go implement it with whatever tools and techniques you see fit.
This is what “data-oriented” programming means to me. It’s not some elegant code abstraction. It’s mostly just a process involving people and business.
Even for non serious business, these techniques can wrangle complexity that would otherwise be insurmountable.
I still think the central piece of magic is embracing a relational model. This allows for things like circular dependencies to be modeled exactly as they are in reality.
Once you have a relational schema that the business can look at and understand, then you go implement it with whatever tools and techniques you see fit.
This is what “data-oriented” programming means to me. It’s not some elegant code abstraction. It’s mostly just a process involving people and business.
Even for non serious business, these techniques can wrangle complexity that would otherwise be insurmountable.
I still think the central piece of magic is embracing a relational model. This allows for things like circular dependencies to be modeled exactly as they are in reality.