今、ソフトウェアシステムはもちろん、それに応じて、アーキテクチャの役割がますます明らかになってきた、より複雑になります。開発者として、私たちは建築のために、その過程で、毎日、建築を扱っていることが多いさまざまな問題を生み出すもあります。
- アーキテクチャとは何ですか？問題を解決するために、それぞれ、分類スキーマは何ですか？
- 優れた建築デザインとは何ですか？どうすれば良い建築家としてそれを育てることができますか？
これらの問題は、アーキテクチャの我々の理解に関係するだけでなく、建築を学び、使用を開始します。だから、今日、私たちは徹底的に建築の本質を分析する必要があるので、あなたはそれを徹底的に理解することができます。
アーキテクチャの本質
物理学は非常によく知られている「エントロピー増加の法則」があります：クローズドシステム、すべての注文から無秩序に、そのエントロピーである（すなわち、障害程度）が増加し続けると、システムは、最終的には完全に乱れなります。
ソフトウェアシステムの進化にこの理論では、それはまた、非常に適しています。
一方で、増加のビジネスニーズに、我々はシステムにビジネス機能を追加していきます。一方で、増加したトラフィックで、我々は技術的手段を介してシステムに非動作機能を強化していきます。あなたは、時間の進行とともに、設計の前にうまくやっていない場合は、システム全体が、より多くの混沌とした、野蛮な成長である次第に断片化し、最終的には車輪の再発明。
しかし、生物の性質は、外の世界と対話することができ、ある「負のエントロピー」、製アクティブ代謝は、生き残るために続け、彼らの秩序を確保するために、混乱を減らします。例えば、有機合成における光合成、光エネルギー、二酸化炭素及び水を介して植物は、自分自身を養うために、生存し続けます。ソフトウェアシステムでは、我々はまた、より良いビジネスの成長や技術の変化に対応するために、全体的な整然としたシステムを確保、システムのさまざまな部分との間の関係を調整するためのイニシアチブを取ることができます。調整ようなシステムの内部関係はアーキテクチャによって実現されているので、アーキテクチャは、本質的に：
合理的な内部レイアウトすることで、変化するビジネスと技術を満たすために拡大する可能性の高い注文システムを、確認してください。
これには二つの意味が含まれている、我々は、特に下に展開したことを言いました：
まず、開始点は、システムパニック、アーキテクチャを通じて秩序を確保する必要が生じ、ますます複雑で、ビジネスと技術のアーキテクチャです。私たちは、言葉は平均建設業界は、「フレームワーク」を必要とする理由、建設業、建築、から来ていることを知っていますか？
カバー層2、より複雑な少しを構築しますが、経験豊富な職人の指導の下、問題は大きくない;わらの家は、あなたが直接、非常にシンプルに始めることができているビルドと高層複合体を構築することはかなり異なっている、と我々は考える必要があります内部構造、耐荷重、照明、排水、地震雷など、ウェル全体建築設計の事前に専門家を必要とし、厳密に構造に設計に従っています。
ここでは、建物の建築が自然ではなく、なぜなら建物は、ますます複雑なことを見ることができ、我々は建設プロセスの制御の損失を避けるために、アーキテクチャにより、この複雑さを管理する必要があります。
同じことが、簡単なデスクトップアプリケーションから、今日の大規模なインターネットプラットフォームに、ソフトウェアシステムの真である、プロセス、システムの大規模化、ビジネスと技術はますます複雑になってきています。我々はまた、建築設計に必要な、システムの複雑さに起因する消化器疾患は、整然とした状態で常に現在および将来のニーズの変化に応答することができます。
第二に、アーキテクチャは、順番に障害を達成し、合理的な内部レイアウトによる基本的な手段を実現し、より合理的な関係を形成するためにそれらを再結合し、「分離」と「一緒に」、解散する最初のシステムであり、 。
具体的には、「サブ」システムは、サブシステム、モジュール、コンポーネントに分割されます。スプリットタイムは、私たちが最初に私たちは、より身近なマイクロサービスアーキテクチャは、各部品を配置する問題を解決して、位置に基づいて、互いの境界から分割し、最終的に合理的な分割を達成しなければならない、それは典型的な分割アプローチです。
「統合は、」ビジネスプロセスとテクノロジー、一緒に様々な要素の有機的統合に基づいています。例えば、マイクロアーキテクチャにおけるサービスプラットフォーム、特定のマイクロサービスに分割、我々は可能な限り、これらのサービスと成層、基本サービスに属するいくつかの、上側のアグリゲーションサービスに属するいくつかを分類するために、だけでなく、サービスを実装する必要がありますそのような私たちは一緒にアイデアに反映されている台湾で最近言ったように。
2つのレベルに共分解システムのプロセスの複雑さのこのポイント。
- まず、各サブシステムが独立して責任を負い、独自の内部の複雑さが含まれています。サブシステムの複雑さが外に透明であり、外側は気にしません。
- 第二に、ポイントの明確な責任に縮小パッケージを介してサブシステムは、したがって、我々はあなたが全体のシステムを定義することができますので、様々なポイント間の解決の依存関係、でクローズ時にのみ必要です。
例えば、その主なロジックだけで、アセンブリのさまざまなコンポーネントに与えられる必要があり、23のGoFのデザインパターン、ビルダーモードことを知っている私たちは皆、それは、内部ロジックの特定のコンポーネントを作成するには、この缶賃金を気にしません工場出荷時のモデルに実現しています。ここでは、Builderのモードは、それがクマの部分に結合され、ロジック粗粒を組み立てるための責任があり、きめの細かい構造を担当する工場モードロジック、サブセクションことを、私たちそれぞれが自分の複雑さを管理を前提としています。
合理的な「分離」と「一緒に」とは、システムがバック振り出しにではなく、システムの元のモノリシック構造は、柔軟なシステムとなります。したがって、システムの効果的かつ整然としたのシステム分解の複雑性が大幅に向上。
もちろん、システムの複雑さが多く、技術およびビジネスアーキテクチャには、あるシステムであり、これらの複雑な課題に対処するために一緒に様々なアーキテクチャが存在します。それでは、私たちは、特定の外観に来ます。
カテゴリーアーキテクチャ
異なる角度によると、アーキテクチャは、分類の多くを持つことができるが、一般的に、ビジネス・アーキテクチャ、アプリケーションアーキテクチャと技術アーキテクチャに分け。だから、これらのアーキテクチャは、問題を解決するために、誰にサービスを提供している、それはお互いの関係は何ですか？
これらの質問に答える前に、まず着陸プロセスのシステムを見てください。
システムは、最初のマシンで実行し、人々によって開発され、機械のアースは、システムに参加します。
開発責任者のために、より多くの面倒は、現在の力コードにビジネスロジックは、システムのメンテナンスもフォローアップの質問であったとしても、ビジネスがあまりにも明確に考えるように、心を複雑化することです。このように、開発者が必要とされるシステムの概念は、容易にそのビジネス・ロジック、コード開発が視覚的に明確に理解されます。
マシンを実行するための責任、面倒は外部からの要求によって複雑にされているマシンが運ぶことができなかった原因、大きすぎると、時々、ハードウェアが間違って行くでしょう。したがって、システムは拡張、ハードウェアのフォールトトレランスのためのサポート、高い性能とシステムの可用性を確保することが可能である必要があります。
ここでは、主要な痛みポイントの開発は、アプリケーションアーキテクチャとビジネスアーキテクチャによって解決されるように、技術的なインフラストラクチャによって、マシンの主な痛みのポイントが解決します。
なぜあなたは言うのですか？私たちは、見て、これらのアーキテクチャは、とやるために特別に何をしています。
簡単に言えば、事業構造が明確なコアビジネスプロセスである、様々なビジネスモジュール間の関係を定義し、それは、私たちは、システムが直面しているものと概念レベルからに対処する方法を理解するのに役立ちます、そして明確であるアプリケーション・アーキテクチャは、どのように組織の内部システムであります、どのようなアプリケーションでは、お互いを呼び出す方法であり、それは私たちが労働力と論理レベルの協力の部門のどの内部システムを理解するのに役立ちます。
技術的なアーキテクチャは、我々が開発したアプリケーションがあり、どのようにシステムの安定性を維持するため、異常な状況の様々な対処するために、一緒にフィット利用可能であるか、ハードウェア、オペレーティングシステム、およびミドルウェアで構成されたシステムは明らかです。だから、物理的なレベルからの技術アーキテクチャは、私たちは、システムが構成されている方法を理解し、安定性の問題を解決する方法を支援します。
ここでは、ビジネス・アーキテクチャ、アプリケーションアーキテクチャと技術アーキテクチャを参照してください概念、論理的および物理的なレベルからシステムを定義することができます。ビジネスアーキテクチャはまた、概ね労働およびコラボレーションアプリケーションの分割は、当然のことながら、そのような商品の事業として、厳格な対応を必要としない方法を決定する事業部門と依存関係モジュールを与え、それは3つのアプリケーション、商品表示前景に対応することができますアプリケーション、バックグラウンド商品管理アプリケーションと同様に、基本的な商品サービスが、これは私たちに影響を与えませんが、論理的に参加して適用されるビジネスシナリオを、理解し、彼らが協力する方法。
安定動作で、それの技術的なアーキテクチャは、アプリケーションをサポートし、最終的にはビジネスの無い問題を確保します。例えば、大きなプロモーションは、複数のアプリケーションは、大流量の影響によって影響を受ける可能性があるとき、私たちは大きなプロモーションの円滑な進行を確保するように、技術的手段を通じて技術のアーキテクチャは、高並行性を扱うことのできる関連するアプリケーションを保護する方法を検討する必要があります。
ここで、私は、これらの3つのアーキテクチャの関係のあなたがより直感的な理解を助けるために、映画を作るの例を与える：ビジネス・アーキテクチャは、この映画とシーン構成のストーリーを定義し、アプリケーションフレームワークは、さらにどのような役割を定義し、それぞれの関税、および各シーンで、どのようにこれらの役割が相互作用し、技術的なアーキテクチャこれらの役割を実行する人完成させるために、シーンの物理的なレイアウトは、順番に全体の撮影が正常に完了したことを確実にする方法、です。
最後に、私が強調したい：システムは、人間のシステム・アーキテクチャは、最初のサービング他人です。そのため、ビジネスコンセプトは、最初にその善良な人々を理解すること、分業の明確な、合理的な使用です。我々は、システムの非機能的目標の実現を確保するために、技術選択の問題を考えます。アーキテクチャ設計を行う際に、一般的には、ビジネス・アーキテクチャ、アプリケーションアーキテクチャ、その後、最終的には、技術のアーキテクチャを検討することです。
優れたアーキテクチャとは何ですか？
ビジネスの複雑さと技術的な複雑さ：以上のことから、我々は良いアーキテクチャは、2つの課題を満たさなければならないことがわかります。
1.事業の複雑
システムは、最初にこれに基づいて、また会う将来のビジネスニーズに、現在のビジネス要件を満たす必要があり、そのシステムは、既存の機能の調整を含めた変更を、展開し、新しい機能を追加していくことができるはずです。
また、システムは変更が既存のビジネスではなく、変更に影響を与える機能しないことができ、それはどこでも、身体を起動し、問題を導きました。したがって、フレームワークの設計で、柔軟かつ可能なシステム柔軟な拡張性のは、ビジネスの変化に応じて調整を行うことにします。
同様の新規事業に再び、ビジネス上半年、この時間を費やし前に加えて、新たなビジネス上の誰のための市場が待機、高速であることを、我々は短い時間に落ちることができるようにする必要があります。したがって、フレームワークの設計だけでなく、システムの機能を達成するために、迅速な、ビジネスの俊敏性と革新を通じてので、再利用すると、再利用することができます。
2.技術的な複雑さ
ビジネス機能を満たすためだけでなく、事業の正常な動作を確保するために、だけでなく、このシステムは安定して使用可能であることを保証します。
複雑なシステムは、このようなアプリケーション、サーバ、データベース、ネットワーク、ミドルウェアなど、多くのコンポーネントで構成され、間違って行く可能性が高いです。物事がうまくいかないとき、すぐにトップのlet外出先でシステムまたはバックアップシステムを復元することができますどのように？
交通問題は、トラフィックは通常、マシンは少量を扱うことができるものではなく、大きなプロモーション、多くのトラフィックが入ってくるとき、システムは単純な方法を追加することで、マシンをサポートできることができないが、ありますか？
システムが行うことができ、低コストの問題は、仮想化技術ではなく、物理マシン、およびトラフィックの低いを使用して、代わりにオープンソースコンポーネントの代わりに、高価な商用パッケージの背の高い、無料でご利用に安価な機器IOE機器を使用するのでもありますピークは、異なる時間に、そのシステムは、ボリュームの減少とそれの拡大弾性できること？
これらは、また、アーキテクチャをサポートするように設計され、非動作機能のシステムを解決するための技術的な課題です。
そのため、優れたデザインは、会うビジネスアーキテクチャのスケーラブルなだけでなく、再利用可能なはずです。我々は、高可用性システム、および高性能スケーラブル、費用対効果の高い方法と可能な限り着陸などを満たす必要があります。だから、建築デザイン、技術とビジネスのために両手を両手でつかみます。
だから、良い建築家は、良い構造を設計するためには、能力の種類を持っている必要がありますか？
良い建築家とは何ですか？
優れた建築家は、私は典型的なアーキテクチャを経由して来るここで「キッチン、リビングルームの下で」、の内部と外部の強力な総合力を持っている必要があり、優れた建築家を導入する能力は持っている必要があります。
これらは非常に実用的な作品ですので、水泳のコーチ、確かに水泳の良いレベル、スキルを駆動する駆動学校のインストラクターが、良いことがあります。同じ建築家は、TAは良い手の書き込みコードへの良好なプログラマーである必要があります。
これに基づき、建築家は、技術（マルチドメイン知識）と深さ（技術先見の明）の広さを持っている必要があります。同社の主流のシステム設計は、実用上の問題の顔の長さのメリットを知っている、私たちはすぐに評価のための様々なプログラムを提供することができるようになります、非常に理解しています。
また、建築家は、抽象的思考能力と、思考の高い学位を持っている必要があります。抽象的思考能力が最も重要な建築家、建築家は親切概念化と分類に良いことがあります。例えば、大規模なB2Cサイトの顔は、すぐに抽象調達することができます - >操作 - >フロント検索 - >注文 - >シングルは、システムの分割統治のこれらの主要なモジュールを果たします。
建築家はまた、思考の深さを持っている必要があり、問題の本質を見抜くことが可能です。問題を越えて見るには、深いレベルの採掘に、本質への物事の出現によって引き起こされます。例えば、それはJVM（Java仮想マシン、Java仮想マシン）で実行する方法を知っている、Javaコードのセクションを参照して、クロスネットワーク呼び出し、（例えばLANポートなど）様々なメディアを介して目標位置データに到達する方法を知っています。建築家を有効にする問題を越えて見るには、迅速に問題を考えるための閉ループ方法をエンド・ツー・エンドの基礎となる真実を発見し、システムは欠点を特定し、それを解決することができます。
別の非常に重要な点は、建築家はまた、当事者が協調行動を取って喜んフレームワーク、上の合意に達することを保証するために、良好なコミュニケーションスキル（感情的）を持っている必要がありますので、アーキテクチャは、優れたアーキテクチャを着陸することができ、かつ良好なトレードオフそのリソースの制約を確保するために、既存の枠組みの下での容量（理由は）、最も合理的である、最終的に現実に最適です。