What I meant is that you need a good separation of concerns for the microservices. Each microservice is owned by a different team, so if you need to change som

What I meant is that you need a good separation of concerns for the microservices. Each microservice is owned by a different team, so if you need to change something that touches 2 or more, you need to collaborate with other teams...this adds a lot of overhead. Not to mention that it becomes almost impossible to do real re-architecting: you can't really move data flows or code from one microservice to another. In my experience you're more likely to end up with duplicate flows, duplicate code, just because it's too damn hard to move "class X" from A to B. In a monolith you can and often do those kinds of changes. It's also easier to have unit tests. It's easier to have integration tests that are still fast and self contained. Sure, you might say that unit tests are easy to write in any scenario but what I mean is maintaining them becomes easier, especially if you're doing Detroit style. It's easier to not break them when doing larger refactorings.