目次
1 ソフトウェア アーキテクチャ システム
予備知識: インターネット アーキテクチャの進化https://blog.csdn.net/ZGL_cyy/article/details/126330968
1.1 システムとサブシステム
システム: 一般に、特定の規則に従って動作し、個々のコンポーネントが単独では実行できない作業を完了することができる、関連する個人のグループで構成されるグループを指します。
- 関係: システムは関係のある個体の集まりで構成されており、関係のない個体はシステムを形成できません。例えば、自動車のエンジンとりんごの束を合わせてもシステムとは言えず、エンジン、シャシー、タイヤ、フレームを組み合わせて初めて自動車となり、システムを構成することができます。
- ルール: システム内の個人は、個々の個人が独立して行動するのではなく、指定されたルールに従って操作する必要があります。ルールは、個々の分業とシステムの連携の仕方を規定しています。たとえば、車のエンジンは動力を発生させ、その動力はトランスミッションとドライブ シャフトを介して車輪に出力され、車を前進させます。
- 能力: システム能力と個人能力には本質的な違いがあり、システム能力は個人能力の総和ではなく、新しい能力です。たとえば、車は荷物を前方に運ぶことができますが、エンジン、トランスミッション、ドライブ シャフト、および車輪自体にはこの能力がありません。
サブシステム: サブシステムは、関連する個人のグループで構成されるシステムでもあり、おそらくより大きなシステムの一部です。サブシステムの定義は、システムの定義と同じですが、観察の角度が異なります. システムは、別のより大きなシステムのサブシステムである場合があります.
分析を行うための例として、WeChat を取り上げます。
- WeChat 自体は、チャット、ログイン、支払い、友達の輪などのサブシステムを含むシステムです。
- サークル オブ フレンド システムには、更新、コメント、いいねなどのサブシステムも含まれています。
- コメント このシステムには、アンチブラシ サブシステム、監査サブシステム、リリース サブシステム、およびストレージ サブシステムが含まれる場合があります。
- コメント レビュー サブシステムには、ビジネス上の意味でのサブシステムは含まれなくなりましたが、別の次元のシステムでもあるさまざまなモジュールまたはコンポーネントが含まれています。たとえば、MySQL、Redis などはストレージ システムですが、ビジネス サブシステムではありません。
1.2 モジュール、コンポーネント、サービス
- モジュール: 一貫した密接に関連するソフトウェア組織です。これには、プログラムとデータ構造の 2 つの部分がそれぞれ含まれます。現代のソフトウェア開発では、モジュールを構成単位として使用することがよくあります
- コンポーネント: アプリケーションの組み立てに簡単に使用できる、自己完結型、プログラム可能、再利用可能、言語に依存しないソフトウェア ユニット
モジュールとコンポーネントはすべてシステムの一部ですが、システムはさまざまな角度から分解されます。例えば：
- システムを論理的に分割した単位が「モジュール」であり、システムを物理的に分割した単位が「コンポーネント」です。
- モジュールを分割する主な目的は責任の分離であり、コンポーネントを分割する主な目的はユニットの再利用です。
たとえば、学生情報管理システムを作成したい場合、このシステムは論理的な観点から分割でき、ログイン登録モジュール、個人情報モジュール、および個人成績モジュールに分割でき、物理的な観点から分割できます。アプリケーション、Nginx、Web サーバー、MySQL などに分割できます。
- **サービス: **サービスとコンポーネントには一定の類似点があります。これらは外部アプリケーションによって使用されます。この 2 つの最大の違いは、コンポーネントはローカルで使用され (Jar ファイルなど)、サービスは実行され、同期または非同期のリモート インターフェース (RESTFul インターフェース、Web サービス、メッセージ システム、RPC、ソケットなど) を介してリモートで使用されることです。
サービスは、独立して実行でき、外部に機能を提供できる形式です。複雑なプロジェクトを複数のサービスに分解することができます。特定のサービスがハングアップしても、システム全体がダウンすることはありません。サービスがなければ、新しい機能がシステムに追加されるたびにすべての機能に影響します; サービスが採用された場合、各サービスはその上流と下流のサービスのみを担当します。
1.3. ソフトウェア アーキテクチャ システム
2 アーキテクチャの原則
2.1 デカップリング
ソフトウェア エンジニアリングでは、カップリングはオブジェクト間の依存関係を指します。オブジェクト間の結合が高いほど、メンテナンス コストが高くなります。したがって、クラスとコンポーネント間の結合を最小限に抑えるようにオブジェクトを設計する必要があります。ソフトウェア設計では、通常、結合度と凝集度がモジュールの独立度を測る基準として使用されます。モジュールを分割する基準の 1 つは、凝集度が高く、結合度が低いことです。
結合はさまざまな分野に存在し, ソフトウェア設計に固有のものではありません. 理論上, 絶対ゼロ結合は不可能ですが, いくつかの方法を使用して結合を最小限に抑えることができます. 結合度を減らすことは、デカップリングとして理解できます.デザインは[互いに独立し、独立している]。
2.2 レイヤリング
階層構造は、アプリケーション ソフトウェアの最も一般的で広く使用されている設計手法です。階層構造を持つシステムでは、各サブシステムが階層形式で編成され、上位層は下位層のさまざまなサービスを使用しますが、下位層は上位層について何も知りません。各レイヤーは、その下のレイヤーの詳細をその上のレイヤーから隠します。
従来の 3 層アーキテクチャ:
ソフトウェア アーキテクチャでは、従来の 3 層アーキテクチャは、上から順に、ユーザー インターフェイス層、ビジネス ロジック層、およびデータ アクセス層で構成されます。この階層化されたアーキテクチャが提案された時代には、ほとんどのシステムは比較的単純で、基本的に単一アーキテクチャのデータベース管理システムでした。この階層化されたアーキテクチャは、ビジネス ロジックとデータ アクセス ロジックを効果的に分離し、これら 2 つの異なる関心事が比較的自由に独立して進化できるようにします。従来の 3 層アーキテクチャは次のようになります。
レイヤー化の設計原則は、同じレイヤーのコンポーネントが同じ抽象化レベルにあることを確認することです。これがいわゆる「単一レベルの抽象化の原則」です。この原則は、レイヤード アーキテクチャに適用できます。たとえば、次の図に示すように:
2.3 包装
いくつかの異なるオブジェクトを論理的に持つプログラムがあり、これらのオブジェクトが互いに通信するとします。
クラス内では、各オブジェクトの状態が比較的分離されている場合にカプセル化が達成されます。他のオブジェクトは、このオブジェクトの状態を監視できません。彼らができることは、「メソッド」と呼ばれるいくつかの一般的な機能を呼び出すことだけです。
したがって、オブジェクトはメソッドを使用して自身の状態を制御し、明示的に許可されていない限り、他の誰もオブジェクトに触れることはできません。オブジェクトと通信する場合は、提供されているメソッドを使用する必要があります。ただし、デフォルトでは、オブジェクトの状態を変更することはできません。
3 アーキテクチャのアプローチ
アーキテクチャ図は、ソフトウェア システムの全体的な概要、さまざまなコンポーネント間の相互関係と制約境界、およびソフトウェア システムの物理的な展開とソフトウェア システムの進化方向の全体像を表すものです。利害関係者がアーキテクチャに関する決定を理解し、従うためには、アーキテクチャに関する情報を伝える必要があり、アーキテクチャ図は優れた媒体です。視点と役割が異なれば焦点も異なり、表示されるアーキテクチャ図も異なります。
3.1 ビジネス アーキテクチャ
ユーザー: CEO、CIO、CTO、プロダクト ディレクター
コア ビジネス プロセス:
コアコンピタンス：
3.2 機能アーキテクチャ
ユーザー: プロダクト ディレクター、プロダクト マネージャー
**例:** Toutiao 機能アーキテクチャ図
3.3 システムアーキテクチャ
使用者: システム アーキテクト
3.4 技術アーキテクチャ
使用者: システム アーキテクト
例 1 : https://www.processon.com/view/5f2a0bfb1e08533a629b7ed3
例 2 : コールド チェーン プロジェクトの技術アーキテクチャ図
3.5 データ アーキテクチャ
ユーザー: CTO、システム アーキテクト、データ アーキテクト
例 1 : データ モデル
例 2 : ビッグ データ プラットフォームのアーキテクチャ
3.6 配備アーキテクチャ
ユーザー: オペレーション アーキテクト
例 1 : https://www.processon.com/view/5f2a03cf637689168e49e3fa
例 2 : コールド チェーン プロジェクトの展開アーキテクチャ図
