アプリケーションアーキテクチャ-大きなシステムが少ないvs小さなシステムが多い

re：アプリケーションアーキテクチャ、つまり、「組織が複合アプリケーションを作成するために使用している一連のアプリケーションが、スケーラブルで信頼性が高く、利用可能で管理しやすいことを保証する科学と技術」

組織内のさまざまなアプリケーションを見ると、アプリケーションをマージするさまざまな理由がわかりますが、それらを分離しておくことの良い理由も時々あります。

一般に、大きなシステムが少ない場合と小さなシステムが多い場合の長所と短所は何ですか（多くのシステムが情報を交換することを覚えておいてください）。

私は次のようなことを考えています：小さい、大きいアプリはアプリ間の配管が少ないことを意味しますが、小さいアプリが多いほど個々の部門の柔軟性が高くなります。

これに関する文献はありますか、または誰かが発見した長所と短所のリストを持っていますか？

編集：私のシナリオでは、多くのアプリは社内で開発されたものではなく、既製のものでカスタマイズ可能ですが、より一般的なシナリオを自由に検討してください。

頭のてっぺんから

より小さなシステム

• プロ -コモディティ・ハードウェア、または安価な仮想化環境にスケールアップ。
• プロ -クラウドでオンデマンドスケーリングを実装できます。
• プロ -少数のイントラシステムの依存関係、すなわち。サーバーごとに1つのサービス。
• Pro -HA / DR（高可用性/災害復旧）は通常、実装が簡単です
• 短所 -水平方向にスケーラブルでなければならない
• 短所 -システムが多いほど、相互接続が多くなり、管理がより複雑になります

より大きなシステム

• プロ -相互接続が少ないため、通常はそれほど複雑ではありません
• プロ -許容範囲内にある場合、ピーク使用率が高い場合により速く応答します。
• プロ -管理するリソースが少ない
• Pro-より効率的なリソースの使用（比較的一定した使用を想定）
• 短所 -より複雑なシステム内依存関係、つまり サーバーあたりN個のサービス
• 短所 -HA / DRは通常、より困難/複雑です

大規模なシステムでは、次のことがはるかに簡単です。

• 機能とコードを共有します。ホイールの再発明は少し少なくなります。たとえば、データベースへのアクセスが必要なアプリケーションが10個ある場合、すべてのアプリケーションで接続文字列を 10回指定する必要があります。または、別のライブラリを作成して、再度10回参照する必要があります。

• 展開プロセスを含むワークフローを統合します。

• システムの管理：一般に、管理するアプリケーションが少ないほど簡単です。

• ユーザーエクスペリエンスを統一します。従業員が10の異なるアプリケーションを処理する必要がある場合、彼は簡単に失われる可能性があります。Aを実行するために実行するアプリケーションは何ですか？どのアプリケーションでオプションBを利用できますか？しかし、統一しないでください。Word、PowerPoint、Outlook、Publisher、Visio、Project、Grooveを単一の一体型アプリケーションとして評価する人はいません。

一方、小さなシステムの束では、次のことがわかります。

• システムが不要になった場合は、システム全体を破棄できます。または、コードベースが時間の経過とともに使用できなくなった場合は、ゼロから始めます。もちろん、これが当てはまるのは、他のシステムがこのシステムに依存していない場合、またはインターフェースが十分に軽く、新しいバージョンで簡単に書き換えられる場合だけです。

• あなたはできる新鮮な開発者のチームを形成し、短い時間で存在しないコードベースを理解するためにそれらから期待します。それが大規模なプロジェクトの一部である場合、大規模なコードベース全体が非常に専門的に行われ、十分にリファクタリングされない限り、より多くの時間が必要になる可能性があります（私はそのようなコードベースを私は見たことがありません）。

• システム管理者は、アプリケーションを簡単に再配置できます。一方、大規模なシステムは、複数のサーバーで適切に拡張できるか、そうでない場合があります。

• 開発者は、コードベースを新しい標準に簡単に移行できます。大きなコードベースの移行は常に恐ろしいです。代わりに、小さなコードベースを処理する必要がある場合、次に別のコードベースを処理する必要がある場合などは、恐怖が少なくなります。

つまり、そのような比較は一般的な場合にのみ機能しますが、プールからではなく、会社の資産から判断する必要があります。どのように構成されていますか？小規模な開発者チームは多数ありますか、それとも少数の開発者チームがありますか？コーディングスタイルなどに関する厳格なガイドラインはありますか？

また、アプリケーション自体にも依存します。たとえば、すべてのMicrosoft Officeアプリケーションを1つのアプリとして出荷するのは不合理です。しかし、たとえば、描画用のアプリケーションと写真のレタッチ用のアプリケーションでAdobe Photoshopを分離すると、生産性も低下します。IMO、製品を統合または分離する決定は、純粋に技術的な決定ではなく、ビジネス上の決定でなければなりません。

最後に、元の質問の2番目のコメントにもお答えしたいと思います。

アプリ内でデータをリンクする方が、アプリ間でデータをリンクするよりも簡単だと思います

それは常に正しいとは限りません。たとえば.NETを扱う場合、WCFを介してさまざまなコンポーネントが交換される単一のアプリケーションを出荷することは珍しいことではありません。この場合、これはWCFを介して通信する一連の個別のアプリケーションに相当します。

もちろん、複数のアプリケーションを処理する必要がある場合は、それらが通信するための何らかの方法を確立する必要がありますが、単一のモノリシックアプリケーションがあるからといって、強制する必要はありません。しかし、本当に大きなモノリシックアプリケーションを作成できるでしょうか。

これを読む。これは、Unixの「多くの小さなプログラム」の哲学です。Linuxでも使用されています。この哲学の広大な持続性（1960年代後半から今日まで）は、それが正しいことであることを示唆しています。

http://en.wikipedia.org/wiki/Unix_philosophy#Eric_Raymond

http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy

http://159.93.17.14/usoft/WWW/LJ/Articles/unixtenets.html

http://www.linuxjournal.com/article/2877