> Business units should always operate in their own code repository and monolith. > Except for new business unit monoliths, we don’t allow new services. This

> Business units should always operate in their own code repository and monolith. > Except for new business unit monoliths, we don’t allow new services. This assumes that your business will not change, that there are perfectly developed interfaces between "business units" (whatever that term means, it's not particularly clear from the doc how large these are). It's nice to say "1 team -> 1 application" but that ignores many realities on the ground. Sometimes domains are "solved" or stable, freeing up a team to work on something else. Should they smash their new work into the same application as their old work just because? What do we do when a team dissolves (ie laid off) but their application cannot be shut down? This article is ok as a case study but is hardly sound advice in general. It does list some specifics about the business being discussed, but then waxes poetic about the entire industry backpedaling from microservices because of interest rates? The only worthwhile thing to take away from this article is that each business is different and should weigh the tradeoffs for themselves.