アーキテクチャとは何ですか?
建築は、橋を架けたり、家を建てたり、基礎を敷いたりする建設分野から生まれました。
古代の知恵に満ちた勤労者は、複雑な建物をその特性に応じて共通の構造部品に分解しましたが、
ソフトウェアも同様で、
人間が主観的に分解して組み立てる限り、建築という概念が使われます。
ソフトウェアアーキテクチャについて話しましょう
ソフトウェア アーキテクチャは、ソフトウェア エンジニアがソフトウェア システムを設計する際にシステム アーキテクチャを定義するための科学的方法です。
これは、機能、パフォーマンス、およびセキュリティの品質特性に焦点を当てたソフトウェア エンジニアによってソフトウェア システムが編成される方法を指します。
言い換えれば、ソフトウェア アーキテクチャは、特定の機能を実現するためにソフトウェア システムをモジュールに分割する技術的手段です。
1: ソフトウェア アーキテクチャは主に 3 つの要素で構成されます
モジュール構造: モジュール構造とは、ソフトウェア システムを特定の機能を実現するためにさまざまなモジュールに分割した構造です。
フレームワーク構造: フレームワーク構造は、特定の機能を実現するために、ソフトウェア システムのさまざまなモジュールを特定の組織形式に従って編成する構造です。
コンポーネント構造: コンポーネント構造は、ソフトウェア システムが特定の機能を実現するためにさまざまなコンポーネントで構成される構造です
。
2: アーキテクチャの階層化
2.1: ビジネス アーキテクチャ
には、ビジネス プランニング、ビジネス モジュール、ビジネス プロセス、システム全体のビジネス分割、ドメイン モデルの関与、実際のビジネスの抽象オブジェクトへの変換が含まれます。
最適なアーキテクチャはなく、最も適切なアーキテクチャだけが存在します。すべてのシステムの設計原則は、最終的な目標としてビジネス上の問題を解決することでなければなりません。実際のビジネスから切り離された技術的および感情的なアーキテクチャは、しばしばシステムに大きな落とし穴をもたらします。
ビジネスの規模と成長傾向を理解する必要があり、高い同時実行性を解決するプロセスは段階的なプロセスである必要があります。
2.3: アプリケーション アーキテクチャ
抽象化層とプログラミング インターフェイスを含む、ハードウェアからアプリケーションまでの抽象化。アプリケーション アーキテクチャとビジネス アーキテクチャは相互に補完的です。ビジネス アーキテクチャの各部分には、アプリケーション アーキテクチャがあります。
独立して展開されるユニットとして、アプリケーション アーキテクチャは、システムの明確な境界を定義します。これは、システムの機能組織、コード開発、展開、および運用と保守に大きな影響を与えます。アプリケーション アーキテクチャは、どのようなアプリケーションを定義するかを定義します。システムはどのように機能し、アプリケーションはどのように役割を分担し、連携するのか
2.3: データ アーキテクチャ
データ アーキテクチャはデータベースの設計をガイドします。開発に関与するデータベースとエンティティ モデルだけでなく、物理アーキテクチャでのデータ ストレージの設計も考慮する必要があります。
2.4: コードのアーキテクチャ
①. コード単位
構成設計
フレームワークとクラス ライブラリ。
②. コードユニット構成
コーディング標準、コーディング規約。
プロジェクトモジュール部門
mvc 設計などのトップレベルのファイル構造設計。
依存関係
2.5. 技術的なアーキテクチャ
技術アーキテクチャ: アプリケーション システムを構成する実際の実行コンポーネント (lvs、nginx、tomcat、php-fpm など)、これらの実行コンポーネント間の関係、およびハードウェアへの展開戦略を決定します。
技術アーキテクチャでは主にシステムの非機能特性を考慮し、システムの高可用性、高性能、拡張性、セキュリティ、拡張性、シンプルさなどをシステムレベルで把握します。
システムアーキテクチャの設計には、ソフトウェアやハードウェアの機能や性能に関する優れた知識が求められ、アーキテクチャ設計の中で最も難しい課題でもあります。
2.6. 導入トポロジアーキテクチャ図（実際の物理アーキテクチャ図）
アーキテクチャ内にデプロイされるノードの数、ノード間の関係、サーバーの高可用性、ネットワーク インターフェイスとプロトコルなどを含むトポロジ アーキテクチャによって、アプリケーションの実行方法、すべてのアーキテクチャのパフォーマンス、保守性、およびスケーラビリティが決まります。財団。この図は、主に運用保守エンジニアが主に焦点を当てます。
物理アーキテクチャでは、主にハードウェアの選択とトポロジ、ソフトウェアからハードウェアへのマッピング、ソフトウェアとハードウェアの相互影響が考慮されます。
3: アーキテクチャのレベル
システム レベル: つまり、システム全体のさまざまな部分間の関係とそれを管理する方法: 階層化
アプリケーション レベル: 単一アプリケーションの全体的なアーキテクチャと、システム内の個々のアプリケーションとの関係。
モジュール レベル: コードのモジュール化、データとステータスの管理など、アプリケーション内のモジュール アーキテクチャ。
コード レベル: つまり、コード レベルからアーキテクチャの実装を保証します。
4: 戦略設計と戦術設計
アーキテクチャ ピラミッドに基づいて、システム アーキテクチャの戦略的設計と戦術的設計を完璧に組み合わせています。
戦略的設計: ビジネス アーキテクチャは、アーキテクトがシステム アーキテクチャを設計する方法をガイドするために使用されます。
戦術的な設計: アプリケーション アーキテクチャはビジネス アーキテクチャに従って設計される必要があります。
戦術的な実装: アプリケーション アーキテクチャが決定したら、テクノロジを選択します。
アーキテクチャとは体系的な思考であり、既存のリソース制約の下で最も合理的な決定を下すために長所と短所を比較検討し、最終的にシステムの骨格を明確にします。これには、サブシステム、モジュール、コンポーネントとそれらの間の協調関係、制約仕様、原則に至るまで、4 つの要素が含まれます
。側面 :
01: 技術の選択、ソリューションなど、体系的な思考に基づく合理的な意思決定
02：システムの骨格を明確にする：システムがどのような部分から構成されているかを明確にする。
03: システム連携関係: ビジネス要求を達成するために各コンポーネントがどのように連携するか
04: 仕様と指導原則を制約する: システムが秩序正しく効率的かつ安定して動作することを保証します。