1.建築とその本質とは
ソフトウェア業界では、アーキテクチャとは何かについて多くの議論があり、誰もが独自の理解を持っています。この王が言った構造と彼が理解した構造は必ずしも同じではありません。したがって、アーキテクチャについて説明する前に、まずアーキテクチャの概念的な定義について説明します。この概念は、人々が世界とコミュニケーションの手段を理解するための基礎です。アーキテクチャの概念の理解が異なる場合、コミュニケーションは当然のことながら行われません。スムーズに。
Linuxにはアーキテクチャがあり、MySQLにはアーキテクチャがあり、JVMにもアーキテクチャがあります。Java開発、MySQLストレージを使用し、Linux上で実行されるビジネスシステムにもアーキテクチャがあります。どちらに注意する必要がありますか？上記の問題を明確にするには、システムとサブシステム、モジュールとコンポーネント、フレームワークとアーキテクチャなど、いくつかの関連する類似の概念を整理する必要があります。
1.システムとサブシステム
システム：関連する個人のグループで構成され、特定のルールに従って動作し、個々のコンポーネントが独立して完了できないタスクを完了することができるグループを指します。
サブシステム：これは、関連する個人のグループで構成されるシステムでもあり、ほとんどがより大きなシステムの一部です。
2つ、モジュールとコンポーネント
これらはすべてシステムの一部であり、システムをさまざまな角度から分割するだけです。モジュールは論理ユニットであり、コンポーネントは物理ユニットです。
モジュールは、システムを論理的に分解すること、つまり分割統治法であり、複雑な問題を単純化します。モジュールの粒度は大きくても小さくてもよく、システム、複数のサブシステム、特定のサービス、関数、クラス、メソッド、関数ブロックなどになります。
コンポーネントには、アプリケーションサービス、データベース、ネットワーク、物理マシン、およびMQ、コンテナ、Nginxなどの技術コンポーネントが含まれます。
3つ、フレームワークとアーキテクチャ
フレームワークは、MVC、MVP、MVVMなどのコンポーネント実装の仕様です。オープンソースフレームワーク（Ruby on Rails、Spring、Laravel、Djangoなど）などの基本的な機能を提供する製品であり、使用できます。直接またはこの二次開発に基づいて。
フレームワークは標準であり、アーキテクチャは構造です。
ここでアーキテクチャを再定義しています。ソフトウェアアーキテクチャとは、ソフトウェアシステムの最上位の構造を指します。
アーキテクチャは、体系的な思考、長所と短所の比較、およびサブシステム、モジュール、コンポーネントを含む最終的な明確なシステムスケルトン、およびそれらのコラボレーション関係、制約仕様、および指針の原則の後、既存のリソースの制約の下で最も合理的な決定です。 。そして、それはチームの全員がイデオロギーレベルで合意するように導きます。
4つの側面が関係しています。
1.体系的な思考に基づく合理的な決定：テクノロジーの選択、ソリューションなど。
2.明確なシステムスケルトン：システムのコンポーネントを明確にします。
3.システム協力関係：各コンポーネントがどのように協力してビジネス要求を実現するか。
4.制約基準と指針：システムの秩序ある効率的で安定した運用を確保するため。
したがって、アーキテクトは、ビジネスを理解し、全体的な状況を制御し、適切なテクノロジーを選択し、主要な問題を解決し、R＆Dの実装を指導する能力を持っています。
アーキテクチャの本質は、現在のビジネス開発に適合し、急速に拡張できるように、システムを整然と再構築することです。
では、アーキテクチャ設計ではどのようなシステムを検討すればよいのでしょうか。理由もなく技術が開発されたり推進されたりすることはありません。アーキテクチャの開発と需要はビジネスによって推進されます。
アーキテクチャ設計は完全にビジネス向けであり、
1.要件は比較的複雑です。
2.非機能要件は、システム全体で重要な位置を占めます。
3.システムには、長いライフサイクルとスケーラビリティの要件があります。
4.システムは、コンポーネントまたは統合のニーズに基づいています。
5.ビジネスプロセスリエンジニアリングの必要性。
2.アーキテクチャの階層化と分類
アーキテクチャの分類は、ビジネスアーキテクチャ、アプリケーションアーキテクチャ、技術アーキテクチャ、コードアーキテクチャ、展開アーキテクチャ、
ビジネスアーキテクチャは戦略であり、アプリケーションアーキテクチャは戦術であり、技術アーキテクチャは機器です。その中で、アプリケーションアーキテクチャは過去と次をつなぐものであり、一方ではビジネスアーキテクチャの実装を引き受け、他方ではテクノロジーの選択に影響を与えます。
ビジネスに精通し、ビジネスアーキテクチャを形成し、ビジネスアーキテクチャに基づいて対応するアプリケーションアーキテクチャを作成し、最後に技術アーキテクチャを実装します。
現在のニーズに適したアプリケーションアーキテクチャを選択する方法と、アーキテクチャのスムーズな移行を確実にするために将来に直面する方法は、ソフトウェア開発者、特にアーキテクトが深く考える必要がある問題です。
1.ビジネスアーキテクチャ（概要アーキテクチャ）：
ビジネスプランニング、ビジネスモジュール、ビジネスプロセス、システム全体のビジネスの分割、ドメインモデルの設計、実際のビジネスの抽象的なオブジェクトへの変換が含まれます。
最適なアーキテクチャはなく、最適なアーキテクチャのみです。すべてのシステム設計の原則は、最終的な目標としてビジネス上の問題を解決することに基づいている必要があります。実際のビジネスから外れた技術的感情アーキテクチャは、システムを大きな穴に陥らせることがよくあります。気まぐれなビジネスに基づかないアーキテクチャ彼らはすべてフーリガンです。
すべての問題の前提条件は、現在直面しているビジネス量の大きさ、成長傾向を把握することです。高い同時実行性を解決するプロセスは、段階的なプロセスである必要があります。合理的な構造により、1〜2年前に事業展開を予測することができます。このようにして、ビジネスの成長をリードするテクノロジーの効果と引き換えに、リーズナブルな価格を支払うことができます。
Jingdongのビジネス構造（オンライン共有図）を見てください。
2.アプリケーションアーキテクチャ（プロファイルアーキテクチャ、論理アーキテクチャ図とも呼ばれます）：
抽象化レイヤーとプログラミングインターフェイスを含む、ハードウェアからアプリケーションへの抽象化。アプリケーションアーキテクチャとビジネスアーキテクチャは補完的な関係にあります。ビジネスアーキテクチャのすべての部分には、アプリケーションアーキテクチャがあります。
同様：
アプリケーションアーキテクチャ：独立した展開可能なユニットとして、アプリケーションはシステムの明確な境界を定義します。これは、システム機能の編成、コードの開発、展開、運用と保守に大きく影響します。アプリケーションアーキテクチャは、システムのアプリケーションとそのアプリケーションの状態を定義します。分割され、協力。ここでのいわゆるアプリケーションは、各ロジックモジュールまたはサブシステムです。
アプリケーションアーキテクチャ図には、次の2つの重要なポイントがあります。
1.責任：アプリケーション（各ロジックモジュールまたはサブシステム）の境界を明確にする
1）論理的な階層化
2）サブシステムとモジュールの定義。
3）主要なカテゴリー。
2.責任間のコラボレーション：
1）インターフェースプロトコル：アプリケーションの外部出力用のインターフェース。
2）コラボレーション関係：アプリケーション間の呼び出し関係。
レイヤリングを適用するには、次の2つの方法があります。
レイヤリングを適用するには、次の2つの方法があります。
1つは水平分割（水平）で、システムをWebフロントエンド/中間サービス/バックエンドタスクに分割するなど、機能的な処理順序に従ってアプリケーションを分割します。これは、ビジネスの深さの分割です。
もう1つは、アプリケーションを業種ごとに分割する垂直分割（垂直）です。たとえば、請求システムは、ビジネスの幅を分割する3つの独立したアプリケーションに分割できます。
アプリケーションの組み合わせは、アプリケーションがどのように連携して複雑なビジネスケースを完了するかを反映します。これは主に、アプリケーション間の通信メカニズムとデータ形式に反映されます。通信メカニズムには、同期呼び出し/非同期メッセージ/共有DBアクセスなどがあります。データ形式は次のようになります。テキスト/ XML / JSON / Binaryなどになります。
アプリケーションの分割はビジネスに偏っており、ビジネスアーキテクチャを反映しています。また、アプリケーションの偏りは、技術アーキテクチャに影響を与えるテクノロジーに偏っています。分割により、ビジネスの複雑さが軽減され、システムがより整然とし、技術的な複雑さが増し、システムがより無秩序になります。
アプリケーションアーキテクチャの本質は、システム分割を通じてビジネスとテクノロジーの複雑さのバランスを取り、システムが分散しないようにすることです。
システムが採用するアプリケーションアーキテクチャの種類は、企業の開発段階やビジネス特性などのビジネスの複雑さの影響を受けると同時に、IT技術の開発段階や社内の技術者のレベルなどの技術的な複雑さの影響を受けます。ビジネスの複雑さ（大量のビジネスを含む）は、必然的に技術的な複雑さをもたらします。アプリケーションアーキテクチャの目標は、技術的な複雑さを回避し、ビジネスアーキテクチャの実装を保証しながら、ビジネスの複雑さを解決することです。
3、データアーキテクチャ
データアーキテクチャはデータベースの設計をガイドします。開発に関係するデータベースとエンティティモデルだけでなく、物理アーキテクチャのデータストレージの設計も考慮する必要があります。
4、コードアーキテクチャ（開発アーキテクチャとも呼ばれます）：
サブシステムコードアーキテクチャは、主に開発者に実用的なガイダンスを提供します。コードアーキテクチャが十分に設計されていない場合、アーキテクチャ全体の設計に影響します。たとえば、社内のさまざまな開発チームがさまざまなテクノロジスタックまたはコンポーネントを使用しているため、会社の全体的なアーキテクチャ設計が制御不能になります。
コードアーキテクチャの主な定義：
1.コード単位：
1.構成設計
2.フレームワークとクラスライブラリ。
2.コードユニットの編成：
1.コーディング標準、コーディング規約。
2.プロジェクトモジュールの分割
3.mvcデザインなどのトップファイル構造デザイン。
4.依存関係
5つの技術アーキテクチャ
技術アーキテクチャ：アプリケーションシステムを構成する実際のオペレーティングコンポーネント（lvs、nginx、tomcat、php-fpmなど）、これらのオペレーティングコンポーネント間の関係、およびハードウェアに展開する戦略を決定します。
技術アーキテクチャは、主にシステムの非機能特性を考慮し、システムの高可用性、高性能、拡張、セキュリティ、スケーラビリティ、および単純さをシステムレベルで把握しています。
システムアーキテクチャの設計では、アーキテクトがソフトウェアとハードウェアの機能とパフォーマンスに関する優れた知識を持っている必要があります。これは、アーキテクチャ設計作業で最も難しいタスクでもあります。