Question

A common goal of software design seems to be to structure an application so that changes impact a minimal amount of components (i.e compiled assemblies) which can then be published individually. Dependency Inversion Principle is applied so stable components don’t depend on volatile ones, classes are packaged in a way again to limit a deployment to a minimal set of components.

So my question is, what is wrong with publishing an entire application in its entirety for each change? Especially if a publish is a completely automated 1-click solution. Surely deploying components individually means I then have to version and manage them individually as mini projects with their own dependencies? A large chunk of ‘good design’ seems to hang on this one principle that publishing each component separately is a good thing, but why?

Answer 1

What is wrong with publishing an entire application in its entirety
for each change?

I don’t think there is anything wrong if you can manage it. It seems this is the approach that Facebook takes:

Because Facebook’s entire code base is compiled down to a single
binary executable, the company’s deployment process is quite different
from what you’d normally expect in a PHP environment. Rossi told me
that the binary, which represents the entire Facebook application, is
approximately 1.5GB in size. When Facebook updates its code and
generates a new build, the new binary has to be pushed to all of the
company’s servers.

Partial deployments can sometimes be useful to maintain a degree of autonomy between component teams but they can result in unexpected behaviours if the particular version-combination of components hasn’t been tested.

However, the motivation for modular design is more around ease of change (evolvability, maintainability, low coupling, high cohesion) than the ability to do partial deployments.