This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries.
Yes, and then they start complaining that the shared domain objects are not kept up to date by team $notMine, and so they inevitably go to a shared library where they fall back into the same issues.
Is that a result of poor DDD, not modelling more appropriate objects? Eg a Customer Address, Delivery Address, Invoice Address Vs just a single shared Address
Or is there still too much conflict for the truly shareable objects?
They can serve multiple purpose and that's not the problem, because there's precedent in the literature -- software architecture the hard parts https://www.oreilly.com/library/view/software-architecture-t... -- for teams to organize architecture review cycles and decide if some microservers are better merged into a monolith. This however requires tons of refactor when microservices aren't design with this part of its lifecycle in mind, and we all know how this kind of investment is risky and hard to communicate to non-technical management.
Microservices exist because of the limitations of a single human brain in being able to wrangle with that much logic at a time.
It is perfectly conceivable that an alien species with different brain characteristics would draw their microservice boundaries at very different points, possibly varying by a whole order of magnitude in either direction.
I don't agree that there are organizational causes even though that's oft repeated as one of the main reasons. I have never seen a one-to-one relationship of microservices and teams irl. Most teams own many services and some services get touched by many teams. In big companies, there are also microservices with zero owners.
One team owning many services is fine, as long as they can deploy them independently of any other team. Less critical (but still useful) is being able to deploy their own services independently of each other.
Some of it is Conway's Law, much though seems purely "cargo cult engineering" or "FAANG cosplay".
Less-competent devs and CTOs hear that Amazon & Google use it, then decide their 12-person team needs to rewrite their product as 5 separate services. I have encountered companies with 50 services where they needed 5, spending 60% of their dev velocity on overhead.
If you're contemplating microservices & haven't already nailed your business transaction boundaries, reliability mechanisms, idempotence, deployment management/ versioning, observability, testability and the operational discipline to run distributed systems you should just stop -- you have no freaking clue and you're going the wrong way.
That's the sane way of using services, but micro-services used in the wild are often used without any organizational consideration at all: as a consultant I witnessed countless of small companies and start-ups who had multiple times more services than developers! (The biggest culprit was the latest one: 61 micro services for 3 devs and a PM, and it wasn't even an outlier) .
What could be a sensible architecture for large orgs has become more of a cult-like behavior that drags everyone down.