まず、アーキテクチャは何ですか
アーキテクチャが何であるかについて、業界では、均一な定義はありませんでした。「エンタープライズアプリケーションアーキテクチャ」でMartin Fowler氏はまた、その定義を与えていない、統一されたコンテンツは、2個のだけのものを挙げることができます。
システム分解の最高レベル。
意思決定システムを変更することは容易ではありません。
「ソフトウェアアーキテクチャは、」本の要約は、学校や学校の意思決定の枠組みの意志からなるように定義されます。
組成派：=アーキテクチャ+インタラクションコンポーネント：システムのソフトウェアシステムのアーキテクチャは、コンピューティング・コンポーネントおよびコンポーネント間の相互作用の間として記載されています。
アーキテクチャを設定=重要な決定を：：ソフトウェアアーキテクチャのいくつかの重要な側面で行われた決定のコレクションを送信することを決定。
コンセプトは、もともと建物のアーキテクチャから派生したので、私はこの問題を考えるために、建物の視点からだと思いました。次のようにウィキペディア、スキーマは、そのアーキテクチャが定義されています。
アーキテクチャは、プロセスと計画、設計、および建物を構築し、他の物理的構造の製品でもあります。
単純な変換は次のとおりです。建物やプロセスの他の物理的な構造と結果のアーキテクチャの計画、設計、施工。
上記の定義から、すべての最初の、究極の目標は、出力アーキテクチャ建物または他の物理的構造に、構造体はちょうど家することができ、それは不動産、または地区、ビジネス地区、あるいは都市ことができています。より大きな構造、より複雑なその構造は避けられません。
第二に、出力建物の前に三つの段階を通過する必要があります：計画（企画）、デザイン（設計）と建物（建設）。これらの3つの段階が実際にアーキテクチャの中核です。その上のセルサイトの構築、建設規模のコンテンツ、建設投資が推定される建設期間と：たとえば、開発者は、最初にそれの全体的な計画を持っている地区を確認し、住宅地を構築したいです。次に、セル設計のあらゆる側面のために、最高レベルは、全体的なレイアウト設計地区もオープン分割し、それはように、不動産デザイン、グリーン設計、様々な施設を設計してあり、その後、精緻化すべきである必要がありますダウンようにアパートの設計、不動産地区内で、様々な通路の設計と各種のです。最後に、建設段階は、建設段階であり、実際の建物の前段階にすべてのアイデアです。そのフレームワークは、上記のプロセスと結果を含みます。
ソフトウェアアーキテクチャの企画、設計、ソフトウェアプロセスと結果の建設：建物がソフトウェアによって置き換えられますのであれば、それは、ソフトウェアアーキテクチャの定義になります。
したがって、最終的な目標は、ソフトウェアのソフトウェア・アーキテクチャは、アプリケーションの出力可能にされるも、そのようなので、上のSaaS、PaaSの、バースやなどのプラットフォーム、および地球の人々が知っているような大規模な都市の生態系のさえ知恵可能より大規模で複雑なシステム、より困難なアーキテクチャ。計画段階より多くの考慮事項は、このようなように、信頼性、拡張性、保守性や、ビジネス機能要件と技術的な非機能要件を含め、需要のソフトウェアであり、この段階でのアーキテクチャのシステム・アーキテクチャ、一般。仕事の設計段階は、多様なニーズを満たすために、より洗練された分割され、この段階のアーキテクチャは、一般的に論理的なアーキテクチャです。この位相アーキテクチャ典型的には物理的アーキテクチャを、メインステージは、ソフトウェアを実装し展開するように構成されています。
第二に、建築と計画
建築と計画が行うには？私は、メインの境界は建築設計の次の段階を計画していると思います。実際の需要のボーダーインフラの影響、。また、アーキテクチャの境界を形成アーキテクチャの形成に制約を、需要。ビジネス要件、機能要件と品質要件：これは3つのカテゴリに分けることができます。
（A）のビジネスニーズ
顧客基盤、企業の現状、今後の開発、予算、プロジェクト、開発、運用、保守に焦点を当て：ビジネス需要がで「ソフトウェアアーキテクチャの設計」で述べた説明し、私は温玉に同意に傾いています、その意味、需要の最高レベルであります商用レベルの目的、期待と制限を含む関与全体のソフトウェアのライフサイクル、を含む商業要因。一般的なビジネスアーキテクチャに比較的大きな影響を与える必要があり、商業の考慮事項に生成アーキテクチャは、このリストに複数の制約より一般的なものの一部になります。
市場への時間：市場への時間は、市場投入までの時間の境界をテストし、設計、開発からシステムを定義します。私は、垂直アプリケーションにフォローアップしていた前に、市場での市場への時間は、新しい学校の前に学生を必要とし、またはそれらは、わずか2ヶ月のために確保開発期間を促進する最善の期間を欠場します。だから、私たちは、クライアントのアーキテクチャやインターフェイスなど、サービス側を再利用するために、モジュールの一部を含め、再利用プロジェクトの前に要素のほとんどを持っていました。もちろん、通常の状況下では、それが開発するような短い時間のために予約されていないが、それは特に長くなりません。すべての面のニーズのバランスを取るために必要な時間の長さに基づいて建築家、優れたアーキテクチャの選択。
コスト見積もり：リソースの境界を定義するためのコストの見積もりを使用することができます。より多くの機能とインフラコストのより品質要件の需要を満たすために、確かに異なる異なるアーキテクチャの開発コストは、限られた予算で、また高いだけのさまざまなニーズを比較検討することができ、重要な優先順位は、需要の高いレベルを満たすことができます。
人間の状況：100開発チームと10人の開発チームは、ソフトウェアアーキテクチャは非常に異なるものになります。また、その技能開発チームの担当者は、アーキテクチャの選択に影響されます。例えば、誰も使わないだろうチームがネイティブに反応選択のための技術基盤がネイティブアプリケーションアーキテクチャに反応として、それはこの段階では適切ではありません。
そして、周辺システムを統合：あなたは、外部システムと統合する必要がある場合、古い周辺システムは、統合がより難しいかもしれない場合は特に、真剣に統合的なアプローチを検討する必要があります。また、制御不可能な因子は末梢系より一般的に、それゆえ、これらの要件に対処するために制御されていないリスクフレームワークはまた、比較的高いです。
オープン：独自システムとオープンシステムアーキテクチャの要件は、あなたがオープンシステムを選択した場合、また異なっており、およびインフラストラクチャの要件の品質が高く、セキュリティ、スケーラビリティ、パフォーマンス、およびその他の品質属性がクローズする必要がありますされていることを閉じたときに比高いです。
市場をターゲット：ターゲットユーザー100,000 1,000,000、10,000,000、ターゲット市場の異なるレベル、アーキテクチャはかなり異なっています。また、専門的な垂直市場とマス市場、およびアーキテクチャは、大きなニッチ市場は、一般的に、計画の製品ラインを使用し、また異なっています。
マルチサポート：今、経営側はまた、その後もWindowsPhone、ブラックベリーをサポートするために行くだろうアンドロイド、iOSの、微信、またはモバイル側と経営側をサポートする、とした場合、PCのWebをサポートする汎用モバイル端末のAndroid、iOSの、微信、管理は通常、エンドサポートサポートVRは、我々はより多くの時間と労力を投資する必要があるが、また、対応する調整アーキテクチャを作成する必要があります。
システムの期待寿命：回答を主観から、誰もシステムが長時間生き残ることができる望んでいないが、より長い生存期間は、システムが変更することができ、拡張性、移植性および他のニーズが高いことを意味します。しかし、市場への時間の制約のために、コストの予算は、ソフトウェア自体の急速な変化と相まって、そう、客観的に、一般的にその寿命が長すぎる期待しないでください。システムは、高まる需要を満たすことができない場合は、基本的に再建することで解決。
段階的な計画は：すべての主要なプラットフォームシステムは、一般的に段階的に行われているので、建築設計の初期段階ではそうで良い再利用性、拡張性、拡張性、移植性の特性とを考慮する必要があります。市場で実績のある、需要後の各ステージは変更する可能性があるので、彼らはオーバーに設計することができないので、しかし、そうでない場合、それはまた、後段のアーキテクチャの調整の難しさを増大させることができる、デザインの廃棄物が発生します。
インターナショナルは：あなたは国際ルートを取るならば、我々はアーキテクチャは、複数の言語のための良いサポートがあることを考慮しなければなりません。
競争相手：その競合他社よりも優れた製品、それは重要な機能や品質の数でお互いをしのぐために持っているだけでなく、これらの分野でのインフラが多くを投資する必要があることを意味します。
法規制は：たとえば、あなたがマスクをフィルタリングするいくつかのキーワードのために、これは私が理解し、天ユニークです。
多様なビジネスニーズ、およびいくつかの需要も、例えば、見積りを販売し、コストに時間が互いに矛盾することができ、システムの寿命が競合する可能性が期待されますが、コストの長い予想寿命が高くなり、時間を投資する必要性より多くなり、市場投入までの時間を遅らせることができます。そのため、建築と計画を行い、ニーズがどの程度に、会ったことが何であるかを明確に区別しなければならないことは、様々な要求間のトレードオフを満たすことができます。加えて、商業的需要が機能要件および品質要件に対して、従って、需要の最高レベルであるのため、優先順位は、一般的に比較的高いです。
（B）機能要件
これは、他のシステムのためのサービスを含むユーザーのためのサービス、などのサービスを、提供しなければならないシステムの機能要件について説明します。アーキテクチャは、主に、機能、サービス、および特定の事業に関連する基本的な機能要件です。したがって、このフレームワークの機能要件を行うには、より良い抽象モデリングするように、ビジネスについて十分に知ることが必要です。アーキテクチャと計画機能要件のうち、主にビジネスドメインモデルを確立します。ドメインモデルが敷設された後、設計の次の段階は、ドメインモデルと一致していなければなりません。
そして、機能ドメインモデリングニーズの前に、需要の下で優先順位を整理する必要があります。影響を受けたビジネスニーズので、機能要件も比較検討する必要があります。例えば、タイト、低コストの予算を市場投入までの期間は、人的資源は、ケースには十分ではありません非常に機能要件は以下を超えることはできませんです。周辺システム時間との統合の必要性、これはまた、いくつかの機能を実現する必要がないことを意味しますが、周辺システムが完全に需要を満たすことができない場合、あなたはまた、独自のニーズを実現する必要があり、その後、行方不明。したがって、この段階で何が需要を満たすために必要性を特徴と？私たちは、会うとどの程度にする必要がありますか？より効果的に特定され、これら二つの問題をモデルにしたフィールドを実行するために。
モデリングの主な分野は、ドメインモデルとの間の関係を分析し、各モデルを理解することです。または直接説明するために例を使用します。（オフラインへのオンライン）支援O2Oを行う電子ビジネスプラットフォームになりましたと仮定し、次はコーミング後にいくつかの重要な機能要件は以下のとおりです。
企業はエンティティが商品であってもよいし、製品プラットフォームを公開することができ、商品もサービスすることができます。
物理的な商品のサポート速達サービスのみの商品には、商人の店の消費量に交換することができます。
ユーザーは、エンティティの商品を購入する際に情報の出荷を提供する必要があります。
各製品を購入するために生成し、ユーザに対応します。
物理的な商品を購入するユーザーが、あなたは、商品の物流情報を見ることができます。
ユーザーが商品サービスを購入するとき、あなたは商人の店の消費量を償還する償還コードの順序を使用することができます。
上記の要件によると、あなたは最初のコンセプト関連分野を取得することができます：ビジネス、貿易、物理的な商品、サービス、商品、物流情報は、ユーザーが格納され、情報、オーダー、交換情報を受信します。後に、これらの概念の技術との間の関係を明確に、技術は、以下のモデルビューと同様とすることができます。
もちろん、これはただの小さな例で、ドメインモデル意志実際にはるかに複雑なこの例より。ドメインモデルの後、システムを決定するためにどのように多くの企業、どのように鮮明な画像上の様々な分野における概念間の関係。
（C）品質要件
品質要件は、需要の3種類があり、最も低いレベルを要求するが、それはほとんどの建築家が最も懸念しているです。非常に多くの技術的なアーキテクチャの概要は、あなたはほとんどが一定の品質や属性の最適化問題を解決するために設計されていることがわかります。
品質は以下の通りです共通の属性：
パフォーマンス（性能）：パフォーマンスは、特に制限されたコンピューティングリソースの場合には、間違いなく非常に重要な機能です。しかし、他の多くの重要な機能を犠牲にして高パフォーマンスのあまり追求、なし。
セキュリティ（セキュリティ）：安全性とパフォーマンスの一般的相互拘束は、最も明白な例は、HTTPSでHTTPSのセキュリティを向上させるを使用していますが、パフォーマンスが犠牲になります。これは、高度なセキュリティと高いパフォーマンス、および特定のニーズに基づいて、両方の性質のバランスをとるため、ニーズを満たすことは困難です。
アベイラビリティ（可用性）：可用性=システムの稼働時間/（稼働時間+システム障害修復時間）：それはまた、一般的として定義され、有効性が知られていました。この定義は、可用性が低く、可用性、およびシステム関連の障害、故障率を説明し、故障率は、可用性が高くなりました。また、高可用性も、故障修理時のシステムが非常に短い説明します。
使いやすさ（ユーザビリティ）：トラブルのない運転の長い時間のためのシステムの可用性を懸念簡単に混乱しての使用や入手の容易は、できない、と使いやすさが懸念されるには、機能を使いやすいシステムです。
堅牢性（ロバスト性）：欠陥に起因する異常な条件の下で、また堅牢呼ば、フォールトトレランス、システムは、不正な操作の際にユーザを指し、またはハードウェアとソフトウェア、システムが依然として機能を実行することができます。例えば、システムの入力エラー、ディスク障害、ネットワークの過負荷や意図的な攻撃の場合は、クラッシュしていない、クラッシュすることはできません、ソフトウェアの堅牢性です。
スケーラビリティ（拡張性）：ユーザデータボリュームと能力の量は、サービスシステムの高品質を維持するときのスケーラビリティを増加させます。例えば、1W、応答時間の同時実行が増加同時実行100Wは、単にサーバの数を増やすことによって、応答時間に到達するためにコードを変更する必要なく、依然として1秒である場合、それは表示されていること、1秒システムの高いスケーラビリティ。
インターオペラビリティ（相互運用性）：相互運用性は、システム内の他のシステムやサービスとのデータ交換の難易度を反映しています。
スケーラビリティ（拡張性）：また、柔軟性として知られているが、変化に対応するシステムの能力を反映しています。ソフトウェア開発プロセスでは、変更の需要が特にモバイルインターネットの時代には、変更が非常に頻繁であるため、スケーラビリティは、品質のモバイルインターネットのプロダクトキー検討のための需要で、一般的です。
明瞭（わかりやすさ）：明瞭度は、プログラム機能、構造、および動作モードを容易にするためにソースコードと関連ドキュメントを介して、開発者を指します。一般的に良好な開発標準に準拠明瞭度を改善することができます。加えて、適切に使用される単一責任の原則では、大幅いわゆるの明瞭度向上させることができます理解するだけの簡単な使いやすい、「シンプルに美しいです」。
テスト容易性（テスタビリティ）：簡単に言えば、テスト容易性をテストし、難易度にソフトウェアのエラーを診断することです。例えば、ユニットテストを容易にします。プログラムは複雑なプロセス・ロジック、データ構造、モジュールの関係が含まれている場合は、設計のテスト容易性がより重要になってきています。
再利用（再利用）：再利用は、他のプログラムで使用することができるソフトウェアコンポーネントの難易度を示します。成分は、典型的には、それが必要とされる一般的な、比較的高い再利用性にコンポーネントの解放を必要とする場合。
ポータビリティ（移植性）：ポータビリティは、異なるオペレーティング環境へのオペレーティング環境からソフトウェアシステムの難易度を示します。
保守性（保守性）：保守性を理解し、正しい、変化を意味し、ソフトウェアの使いやすさを向上させます。私は、最も重要なのは長期生存一つではなく、できるソフトウェアシステムの保守性を確保することであると思います。システムの貧弱な保守性、時間をかけて、実際に体全体に影響を与えるなることを続けるが、それはunmaintainableになり、ゆっくりとしか滅びる発表しました。
理想的には、誰もがすべてのプロパティは、高品質です望んでいないが、誰が、これは不可能であることを知っていません。支払うために困難でコストのかかる必要性を達成するために、より大きな複数のプロパティの品質を向上させるために。また、そのような改善されたセキュリティなどの品質属性との間の異なる制約関係があり、それは一般的なパフォーマンスを低下させる、性能を改善し、またメンテナンスを低減することができます。そのため、実際やっアーキテクチャと計画中の特定のニーズに基づいて品質属性間の優先順位を比較検討しなければなりません。
第三に、アーキテクチャの考え方
ここでのアーキテクチャという考え方は、思考を意味する場合など、建築設計の最高レベル、：プロセス指向、オブジェクト指向、アスペクト指向、サービス指向ようにと。
図1に示すように、プロセス指向（プロシージャ指向）
プロセス指向設計のアイデアは1つのステップに問題を打破するためにある、一歩エグゼクティブにしたがって工程の後に、問題が解決されます。各ステップは、モジュールは、細かい複数のサブプロセスに分割し続けることができるサブプロセスと呼ぶことができる、サブルーチンです。したがって、プロセスは、コア解析の設計、機能的分解、一般にトップダウン、分解の段階的改良するための方法です。大きなプログラムモジュールは次いで、最終的に一つの関数に分解、小モジュールの大多数に分け、大きな複数のモジュールに分け、サブプログラムを複数に分解することができます。
この例では、私はチェスの戦いを借りたい、例は非常に古い記事から来ている：道路の建築家（4）---詳細なオブジェクト指向。以下では、戦闘デザインのアイデア分解を使用するためのプロセスのフローチャートです。
上記の各処理は、機能を達成するために使用し、問題が解決されます。
2つの主な利点のためのプロセス：まず、プロセス明確かつ単純な第二に、高性能。プログラムの高いパフォーマンス要件のために、なぜ多く、これまでマイクロコントローラの開発、ドライバ開発、システム開発やその他のハードウェア関連のソフトウェアとハードウェアで特定の性能では、プロセス指向の方法の設計・開発にまだあります。
プロセス指向の欠点は明らかである：あまりにも第一主、モジュールメインタスクは不均衡を引き受け、第二は、比較的貧弱対向その拡張性、再利用性、保守性をもたらす、機能を拡張することは困難です。第三に、上部及び下部レベルモジュール間のリンクが近すぎる、高結合は、モジュールは、再利用が困難です。
図2に示すように、オブジェクト指向（オブジェクト指向）
プロセス指向の考え方は、実装の詳細に焦点を当て、「行う方法」であり、オブジェクト指向の考え方抽象オブジェクトに焦点を当て、「やるだろう誰」です。カプセル化、継承とポリモーフィズムとオブジェクトの他の特徴は、近いプログラミングを考えるの実世界の道に私たちをみましょう。オブジェクト指向のための手順は簡単に良好な分離、対応する拡張性、再利用性を達成するため、保守性が高くなるが、同時にいくつかのパフォーマンスの犠牲になります。しかし、ハードウェアは急速に発展し、それが何であるかではないのパフォーマンスを犠牲にするポイントです。
オブジェクト指向設計の難易度は、問題領域を1つずつオブジェクトから抽象化、抽象的であり、そしてそれらの間の関係を見つけます。幸いなことに、我々はデザインをよりよくすることができますどのようにデザインパターンの多くSOLID原則とガイダンスがあります。私たちは、ドメインモデリングを行なう方法を案内するフィールド駆動設計手法もあります。
チェスや戦闘の例としては、オブジェクト指向設計のアイデアは、3つの抽象オブジェクトことがあります
選手：行移動し、両方の赤と黒の行動のための一貫した責任を負います。
ボード：ボードは絵を描くための責任があります。
審判：ファウルなどなど、食べるために子供を決定する責任と勝ち負けです。
下記の中図の関係：
対象ラインチェスプレーヤー後、ピースのレイアウトの変化に応じてチェス盤チェス盤画面リフレッシュ・オブジェクト、審判はチェスゲームのオブジェクトが決定されます。
セクション（アスペクト指向）に対向3、
アスペクト指向は、それは、AOPであり、制限を補償するためにオブジェクト指向、オブジェクト指向の拡張です。オブジェクト指向設計では、すべてのオブジェクト階層に散在し、これらの機能を実装してAOP、唯一のコードが存在しない場合には、主になど、ロギング、パーミッションのチェック、トランザクションのサポート、など抽象的なビジネスのカプセル化が、ビジネス以外のコンテンツであり、しかし、オブジェクトの普及に伴い、これらのコードのコアビジネス機能は任意の関係ではありません。このアプローチは、また、重複したコード、および再利用することは困難の多くにつながっています。AOPは、注入システムの表面を横切るこうしてコードの重複を減らすこと、結合の程度を低減するために、拡張性と保守性を向上させるためにするように、事業部とは無関係のものを分離し、生じるこのような問題を解決することです。
伐採許可のチェック、トランザクションのサポート、およびので、独立しても、「断面」として知られている1つのサービスモジュール、内横断的技術の使用は、コア事業から切り離さこれらのビジネス関連サービスを使用できるようにコアビジネスと一般サービス：システムは、2つの部分に分けることができます。コアビジネスは、まだ設計するために、オブジェクト指向の考え方を使用している、ユニバーサルサービスは、アスペクト指向の考え方を用いて実現することができます。
技術の広範な使用に春AOPは、OkHttpインターセプタもAOP設計の実現です。多くの場面では、そのような一貫性のHTTPリクエストヘッダを追加するなど、AOPのアイデアをデザイン統一化ログイン認証を追加し、統合キャッシュを追加し、統一されたエラー処理を追加し、というように、限り、基本的なポイントは、一般的な機能であるとして、AOPを使用することができますすることができます設計および実装するためのアイデア。
4、サービス指向（サービス指向）
今人気のマイクロアーキテクチャかどうか、SOAサービス、思考のサービス指向の方法に基づいています。モノリス、また、単一のアーキテクチャとして知られている：それはサービス指向するために出たとき、あなたは、概念を理解する必要があります。SOAの考え方が存在しない場合には、ソフトウェアのすべての機能を別のパッケージに統合され、その後、単一のプラットフォーム上で展開します。WARパッケージには、すべての機能が含まれていますたとえば、J2EEプラットフォームでは、ソフトウェアシステムは、最終的に標識されるであろうし、Webコンテナに配備します。展開するには、その後、WARパッケージをコピーして複数のWebコンテナを実装するために展開すること。プログラムを変更する必要がある場合はこの方法では、どんなに小さな変化は、新しいWARパッケージを再パッケージ化し、古いWARパッケージにすべてのWebコンテナを交換する必要がありません。
サービス指向アーキテクチャは、別のアプリケーションまたはコンポーネントなどのシステムの異なる機能を分離すると考えサービス、別々の容器に配備異なるサービスと呼ばれる、軽量異なるサービス間の何らかの相互作用のメカニズムを介して通信されます、HTTPなど、RPCが好きです。このように、明らかに緩く結合されたサービスとの間のモノマー構造、機能に比べ、膨張柔軟性の多くであろう。さらに、異なるサービスは、異なるプラットフォームに展開異なるプログラミング言語を使用することができます。
それはプロセス指向、オブジェクト指向、アスペクト指向またはサービス指向であるかどうか、最も本質的な違いはアプローチの異なる角度ということです。実用的なアプリケーションでは、それは思考のフレームワークを使用するだけでなく、さまざまな側面やシステムの異なるレベルを考えると思考について考えるように異なるアーキテクチャを使用することができます。例えば、大規模で複雑なシステムで、あなたが解体サービスの全範囲に考えるサービス指向アーキテクチャーを使用することができ、ビジネス・サービスのコアの側面は、一般的なサービス機能をモデル化したり、アスペクト指向アーキテクチャの再利用オブジェクト指向アーキテクチャの考え方を使用することができます設計することを考えて、当然のことながら、トランザクション処理は、プロセス指向アーキテクチャ最も直感的な思考の使用です。
第四に、建築の原則
思考プロセス指向アーキテクチャからは、サービス指向の存在には、将来的には、新しい考え方があるだろうかわかりません。しかし、どんな考え方の種類、適切なアーキテクチャを設計する方法で私たちを導くことができるアーキテクチャの原則のいくつかの共通点はありません。一方、アーキテクチャ設計、それはプロセス指向であるかどうか、オブジェクト指向、アスペクト指向またはサービス指向に、例外なく、複雑なシステムに主に分解。分解されているもの：だから、それに応じて、我々は3つの質問について考える必要がありますか？どのように分解しますか？どの程度まで分解？これに対応し、これらの3つの質問への回答のためのガイダンスを提供することができる3つの重要な原則があります。
1、関心事の分離の原則
関心事の分離の原則の主要部分は、その懸念から抜け出す、問題のどの部分に複雑なシステムを解決することです。プロセス、オブジェクト、カット、サービス、ちょうど角（も懸念）を打破することは異なっています。比較的単純な問題の複数の焦点に応じて、分解の複雑な問題は、各単純な被験者に対して別々に、これは問題の分離です。分離後、関心のそれぞれの地点から比較的独立し、関心の各ポイントの変化は、実質的に変更して、変更する必要が小さい場合であっても、他の問題に影響を与えません。ニーズが拡大した場合、影響も最小化されます。
懸念の分離は、最も困難が懸念を特定する方法です。焦点が明確に定義された境界とのコンセプトモデル、または「オブジェクト」または「コンポーネント」として、または「カット」や「サービス」など、さまざまな複雑なシステムの抽象化のあらゆる側面をする必要があるものを識別するために、比較的単純な問題への複雑な問題に。
異なる寸法は異なる分離スキームを持つことができます。上記プロセス指向に加えて、サービスを考えるの異なる角度のためのオブジェクト指向、アスペクト指向、いくつかの他の寸法、そこを図から取得され、次の図に示されている。「ソフトウェアアーキテクチャ設計」ブック[2.1懸念の0.1分離]方法：
図は、それぞれの機能的責任、汎用性、粒子サイズの異なる寸法から分離します。責任寸法から分離されたが、3つの階層に分けることができます：プレゼンテーション層、ビジネス層、データ層、対応する懸念がこれです：データ表示、データ処理、およびデータ管理。さらに、データ層は、さらに、ネットワーク層とバッファ層に分離することができます。汎用性の寸法は、共通部分は、部分の一般的な技術、技術、特定のアプリケーションの一部を分離することができます。一般的に、フレームの使用は、一般的な部分的な分離の様々な使用することができます。寸法の観点から、粒子サイズは、別のサブシステムの複雑なシステムに過ぎず、その後、異なるクラスに細分異なるモジュールに分離されます。
実際には、だけでなく、それは寸法を使用するが、複数の次元を考慮すると、異なる寸法の異なる部分は、分離スキームを使用します。例えば、恐らく、責任を多層構造を分離することにより全体的に、その後、粒子サイズに応じて分離し、いくつかのレベルで、例えば、ビジネスサービス層は、異なるモジュールに分離されます。さらに、別の一般的な部分は、例えば、伐採技術分野の一般的な一部の一般的な部分へのアクセス権が分離され、分離されます。
2、高い凝集力と低い結合原理
どのようにシステムが破壊しなければなりませんか？またはどのように懸念の分離すべきか？高凝集および低原則を結合することは、設計上の問題のためのガイダンスを提供することができます。
凝集は、モジュール内部の特徴および要素の近さを意味し、結合手段は、モジュールとモジュールとの間の関連度です。
ポリ機能、逐次重合、重合通信、重合の過程で、重合時間、論理クラスタ、チャンスポリエチレン：良い結束はより多くのに分けることができます。要素の最強最高の結束は、モジュール内の単一の機能を完了するために一緒に働く機能凝集性は、これらの要素が密接に、不可欠リンクされています。凝集は、個々の処理要素及びモジュールは密接機能に関連して、注文を参照して、一つの処理要素の出力の入力要素は、典型的には、前処理された後、これらのプロセスは、順次実行されなければなりません。凝集順序凝集は比較的高いが、多機能に比べ、欠点は、比較的ひどく保守あります。時折それは、モジュール内の様々な要素間の最も弱い凝集凝集、何のつながりはありませんが、誤って一緒に取得します。
データ、タグ結合、コンテンツを連結、結合、外部結合、共通の結合を制御する結合、非直結：良好な結合はまた、複数に分割されています。これは、直接それらの間の直接接触とメインモジュールが最も弱い結合、最強の独立モジュールである、達成する完全介して通話の制御に関係しない二つの非直結モジュールを表します。結合データは、呼び出しモジュールとパラメータモジュールとの間のデータ項目の単純な転送が呼び出されていることを示し、ハイレベル言語で渡された値に相当します。タグ結合はまた、結合特性として知られており、通話が簡単モジュールではなく、データを呼び出し、モジュール間を通過することを示しているが、名前タグであるような結果の名とファイル名などのデータ構造、高レベル言語の名前のようなデータ、および記録データ、実際には、アドレスの転送。モジュールは、間に送信されない制御データを前記結合が、制御情報等フラグ、スイッチ、別のモジュールの制御モジュールの機能として。外部モジュールを結合することは同じグローバル変数への簡単なアクセスの集合であり、グローバル変数パラメータテーブルの情報を通過しません。コンテンツは直接最強に結合されている他のモジュールへのアクセスモジュールに接続されたコンテンツです。
ただ一つの機能を完了するためのモジュールを、できるだけ凝集機能モジュールを達成するために：デザイン原則ハイ結束は言うことです。
カップリングは、モジュール間に存在しなければならない場合、データと結合されるべきで、カップリング以下、注意または共通カップリングの制御された使用を制御し、そして、結合がコンテンツを回避するために、共通の結合の範囲を限定する低結合設計原理と言うことです。
3、適度な設計
適度な設計原則懸念が質問にどの程度のシステムにあります。適度なデザインは、デザインを指しオーバーせず、また不十分。だから、デザインを構成するものの上に？どのような設計上の欠陥を作りますか？要するに、過剰設計すぎて、あまりにも不十分な設計をしたいと思うことです。仮想は良い感じ、それはないですか？私もそう思います。かどうかのデザインが過剰または不十分な決定方法、そのため、および標準的な定量化可能な指標はありません。そのため、デザインはより主観的な判断という、適切です。そしてオーバーやアンダーに設計を回避する方法を、より直感的な個人的な経験も形成されています。
不適切な設計は、主に静止2彼らの不十分なデザインの原因を判断することは比較的容易である：まず、理由設計の初心者で経験不足の原因と、製品の機能と高速な実装のブラインドを追求がスキップまたは大幅な設計点差を縮めたので、第二と。
また、いくつかのオーバーデザインなおじさんボブなど、より明白な例は、クリーンなアーキテクチャを提案し、関心の各点は明確な境界を定義した、建築が本当にクリアされ、保守性、テスト容易性が非常に優れている、高い内部凝集と低カップリング。あなたは小さなプロジェクトの唯一の二、三の開発者の小グループに適用した場合しかし、それは明らかに大規模で複雑な、それぞれが小さな機能を追加する必要があることを発見しただろうが、あなたは多くのコードを記述する必要があります。これは明らかに、適した小規模なプロジェクトのための小さなチームではありません。より多くのスタッフのチームのために、より適したクリーンなアーキテクチャ、および大規模なプロジェクト。
このため、適切な設計かどうかを決定するために、現状ではチームとプロジェクトを分離することができません。また、ビジネス要件、機能要件と品質要件の様々なを含む他の要因現在の状況は、あります。ほとんどの場合、過度なデザインの原因：発生する可能性があり、今後変更についてまず、あまりにも多く、2番目は、設計やデザインの追求です。適切に将来の変化に対応する方法を検討し、その後、適切な設計は、最初の瞬間、需要の瞬間、現在の開発コスト、および現在のプロジェクト担当者の現状に焦点を当てるべきです。将来の変更のために、また可能性を検討する必要がある任意のは、ちょうど90％のこの非常に大きなチャンスに予見可能な将来に発生する非常に大きな機会への変更を検討しています。例えば、ニーズを達成することが決定されているが、理由は少し遅れた優先課題であり、例えば、スタッフの拡張計画を同定されている、ようにして、例えば、ペア11は、取引量が急増する活動に従事すること。
優先順位が識別現在のニーズを満たし、その後、将来的に予見可能な需要はほぼ確実に起こるであろう満たすように設計されるべきである。言い換えれば、適切な設計の原則は、次のように要約することができます。唯一の将来を考慮せずに、現在のニーズを満たすために、それが不十分な設計につながる可能性があり、将来のニーズを考慮するのではなく、あまりにも多くの、過剰な設計につながる可能性が高いです。そのため、最適なバランスで適切な設計は、現在のニーズと将来のニーズのバランスする必要があり、私は、現在のニーズと将来の需要はほぼ確実に起こるだろう考えると思います。
---------------------
著者：bestlove13141516
出典：CSDN
オリジナルます。https：//blog.csdn.net/bestlove12345/article/details/51803053
免責事項：この記事ブロガーのオリジナルの記事、複製など、ボーエンのリンクを添付してください！