I have recently discovered a very good youtube channel about business software development: CodeOpinion. Very concisely yet informative. I highly recommend it. Don't worry - it's OOP-rant free, and all about mainstream accepted good practices, not some wacko OOP-hater like me.
Anyway, while going through some of the episodes I have found a good example of how "Objects" (in OOP) are a metaphor that is just confusing people.
Please watch the AVOID Entity Services by Focusing on Capabilities - it's just 7:30:
In the beginning, the author presents a question asked by someone in the community: "Should I create microservices for each entity?" I was baffled by this idea. It's so ridiculous that I find it surprising that someone would even consider it.
The author of this channel also thinks it's a bad idea and proposes splitting the system along the lines of "capabilities" instead. Which I find very reasonable, natural, and exactly what I would recommend.
Eventually, it occurred to me that whoever asked that question possibly was thinking about all these entities as some individual, autonomous, atomic units acting and communicating inside the system. While the author of the channel did not.
Do not fall into a trap of believing in any "objects" actually modeling any reality. A lot of OOP books push hard that metaphor, but it's harmful. It's a subtle but important difference. There only is, and they're only ever can be, a bunch of data* about things stored and manipulated in the system. These are data about things, so it's convenient to name and talk about them using words for "things", and they will be organized according to the relations between actual "things", but they are not "things" themselves, but "data".
It's so subtle, yet so fundamental, IMO. When you think in terms of "data about concepts" and not confuse yourself believing that the system has any "concepts themselves", it's much more obvious to see that different services will just track different sets of data about the same external "thing".
For this reason, I like the "entity" word much better than "object", and I see BDD, with more strictly data-focused "entities", "aggregates", etc. as a much more reasonable improvement over OOP (even if they share a lot of). (Note: I think I still need to read more canonical literature about BDD, but that's just my view so far).