ソフトウェア設計の一般的な目標は、変更が最小限のコンポーネント（つまり、コンパイルされたアセンブリ）に影響を与え、個別に公開できるようにアプリケーションを構造化することであるように思われます。依存性逆転の原則が適用されるため、安定したコンポーネントは揮発性のコンポーネントに依存しません。クラスは、展開を最小限のコンポーネントのセットに制限する方法で再度パッケージ化されます。
だから私の質問は、変更ごとにアプリケーション全体を公開することの何が問題になっているのかということです。特に、公開が完全に自動化されたワンクリックソリューションである場合。確かにコンポーネントを個別にデプロイするということは、コンポーネントを独自の依存関係を持つミニプロジェクトとして個別にバージョン管理および管理する必要があることを意味しますか？「優れた設計」の大部分は、各コンポーネントを個別に公開することは良いことであるというこの1つの原則にかかっているようですが、なぜでしょうか。
変更ごとにアプリケーション全体を公開することの何が問題になっていますか？
あなたがそれを管理することができれば、私は何も悪いことはないと思います。これはFacebookが採用しているアプローチのようです。
Facebookのコードベース全体が単一のバイナリ実行可能ファイルにコンパイルされるため、会社の展開プロセスは、PHP環境で通常期待されるものとはかなり異なります。ロッシは、Facebookアプリケーション全体を表すバイナリのサイズは約1.5GBだと私に言った。Facebookがコードを更新して新しいビルドを生成するときは、新しいバイナリを会社のすべてのサーバーにプッシュする必要があります。
部分的な展開は、コンポーネントチーム間のある程度の自律性を維持するのに役立つ場合がありますが、コンポーネントの特定のバージョンの組み合わせがテストされていない場合、予期しない動作が発生する可能性があります。
ただし、モジュラー設計の動機は、部分的な展開を実行する機能よりも、変更の容易さ（進化可能性、保守性、低結合度、高凝集度）にあります。