[jcelerier]

> Is this really the go to architecture for enterpire - or more appropriately, large projects?

You have to understand that the context in which this kind of architecture is needed is high-turnovers environments. Basically, in the 90's, managers at big corps - IBM, ATOS, etc... asked the question : "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be productive in a few days ?".

The answer to this is to heavily compartimentalize everything. Your manager tells you that you must implement a very particular behaviour in a very particular class ; you aren't meant to know what's happenning in other parts of the system.

[charleslmunger]

I'd like to reframe this a bit:

> "how can we fire a whole team, hire a whole another team and put them in front of the fired team's code and have them be productive in a few days ?".

What's really happening here is "how can we fire a whole team, hire a whole another team and have the new team be as productive as the old team was?"

You might think documentation, clean architecture, avoid feature creep etc... but what's really happening is that the old team is not productive by any absolute measurement.