This is basically Conway's Law in practice: microservices aren't created because of technical boundaries, but they emerge because organizations need team boundaries.

https://en.wikipedia.org/wiki/Conway%27s_law

▲

figmert 2 hours ago | parent | next [-]

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.

	▲	regularfry an hour ago \| parent \| next [-]
		If you're needing to share code for domain objects between microservices something has gone badly wrong.
	▲	gib444 an hour ago \| parent \| prev [-]
		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?

▲

gchamonlive 2 hours ago | parent | prev | next [-]

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.

▲

roncesvalles 2 hours ago | parent | prev | next [-]

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.

	▲	regularfry an hour ago \| parent \| next [-]
		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.
	▲	inigyou an hour ago \| parent \| prev [-]
		Except microservices don't do that. You still have to wrangle other people's system parts.

▲

stymaar 2 hours ago | parent | prev [-]

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.