Software exists in the real world, and is used to solve real world problem. In building software we inevitably invent or use abstractions to represent or effect real world things. Abstractions that make it easier to do this are good, abstractions that make it harder to do this are just getting in the way.
> In building software we inevitably invent or use abstractions to represent or effect real world things.
Ehhh. Most abstractions I’ve written aren’t abstractions over the real world. They’re abstractions over low level machinery of a computer or program. (Eg there’s no HTTP request and response, DB connection or network socket outside of computer software).
The real world isn’t object oriented. It’s just a bunch of atoms moving around. You can describe physical reality as a bunch of objects that interact via ownership and method calls, but there’s nothing natural about that. OO is no better of a way to describe the real world than actors & message passing, or state & events.
Software that models “the real world” usually describes users, money, addresses and things like that. But none of those things are made out of atoms. There is no money molecule. Money is not on the periodic table. They’re all just another form of abstraction - one that happens to exist outside the software world, that we can capture in part in a database table.
Interesting abstractions are all invented ideas. Some are useful. Some are elegant to express and use in OO code, and some are not.
1 - (Application) System exist in the real world, not software. Software exists in machines.
2 - Computing is used to solve real world problem.
3 - "In building software we inevitably invent or use abstractions to represent or effect real world things." Here is the problem where we part company.
4 - Abstractions that inform computing systems are indeed useful.
[edit+ps]
self disclosure: I've reached 'architectural orbit' numerous times in my career. 30 years later, I am sharing a subtle point. Effective software models cutout attributes of real world elements of the problem domain. All attempt to "model the world" end in tears.
For me, software and tech that is for someone, exists to work for people, who are end users.
End users and customers don't exist to serve at the leisure and pleasure of software and it's creators.
Making people work harder than they need to operate software is selfish.
DevOps and DevEx is important, but if no one uses it with those being great, the Customer and their experience are often lost and never gained.
Learning to model something flexible enough for absorbing and quickly implementing the early customer feedback that is relevant is critical to boring things like retention.
Helping customers earn enough to eat every month, helps the tool makers earn enough to eat every month.
Ironically, (ime/o!h;) it turns out this the "root of evil" plaguing abstraction: thinking that software architecture must map to "the real world".