設計パターンと建築パターンの違いは何ですか？

インターネットでデザインパターンについて読むとき、3つのカテゴリがあることに注意してください。

• 創造的
• 構造的
• ふるまい

しかし、ソフトウェアのアーキテクチャを作成するときは、MVP、MVC、またはMVVMについて考えます。

たとえば、作成パターンの中からシングルトンパターンを見つけましたが、MPVでもシングルトンを使用しました。

だから私の質問は：デザインパターンは製品の全体的な構造ですか？

• はいの場合、シングルトンはどのように設計パターンになりますか？アプリケーションのどこでも使用できるからです。基本的に、メモリ内に一度に1つのインスタンスを作成することだけに制限されていますが、この概念はソフトウェアの設計方法を定義していませんか？

• そうでない場合は、MVP、MVC、MVVMの3つのパターンカテゴリはどこにあるのでしょうか。そして、ソフトウェアの設計とアーキテクチャの違いは何ですか？

詳細な説明が必要ですが、私の知る限りの違いをスケッチしてみます。

パターンは、プログラムに見られる共通点を抽出したものです。これにより、大規模で複雑な構造を分解し、単純なパーツを使用して構築することができます。これは、ある種の問題に対する一般的な解決策を提供します。

大規模で複雑なソフトウェアは、さまざまなレベルで一連の分解を行います。大まかに言えば、建築パターンはツールです。小規模なレベルでは設計パターンがツールであり、実装レベルではプログラミングパラダイムがツールです。

パターンは非常に異なるレベルで発生する可能性があります。フラクタルを参照してください。クイックソート、マージソートはすべて、要素のグループを順番に整理するためのアルゴリズムパターンです。

最も単純なビューの場合：

• プログラミングパラダイム -プログラミング言語に固有
• 設計パターン -ソフトウェア構築で繰り返し発生する問題を解決します
• アーキテクチャパターン -ソフトウェアシステムの基本的な構造編成

イディオムは、低レベルの詳細を埋めるパラダイム固有および言語固有のプログラミング手法です。

デザインパターンは通常、コードレベルの共通性に関連付けられています。これは、より小さなサブシステムを改良および構築するためのさまざまなスキームを提供します。通常はプログラミング言語の影響を受けます。言語のパラダイムにより、いくつかのパターンは取るに足らないものになります。デザインパターンは、エンティティとその関係の構造と動作の一部を具体化する中規模の戦術です。

一方で、建築パターンは、デザインパターンよりも高いレベルで共通と見られています。アーキテクチャパターンは、システムの大規模なコンポーネント、グローバルプロパティ、およびメカニズムに関する高レベルの戦略です。

パターンはどのように取得されますか？使って：

1. 再利用、
2. 分類
3. そして最後に、共通点を抽出するための抽象化です。

上記の考えに従っている場合。シングルトンは「設計パターン」であり、MVCは懸念の分離に対処するための「アーキテクチャ」パターンの1つであることがわかります。

読んでみてください：

1. http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science）
2. http://en.wikipedia.org/wiki/Design_pattern
3. http://en.wikipedia.org/wiki/Anti-pattern

設計パターンは、何度も実証されてきた方法で技術的な問題を解決するためのよく知られたパターンです。設計パターンは、再利用可能なオブジェクト指向ソフトウェアを作成するための一般的な設計構造と実践です。デザインパターンの例は、ファクトリパターン、シングルトン、ファサード、ステートなどです。デザインパターンは、アプリケーション全体の小さな問題を解決するために使用でき、アーキテクチャ全体よりも注入、変更、追加がはるかに簡単です。

アーキテクチャパターンは、ソフトウェアアプリケーションアーキテクチャの問題を解決するためのよく知られたパターンです。ソフトウェアアプリケーションアーキテクチャは、技術的要件と運用要件のすべてを満たす構造化ソリューションを定義するプロセスです。アプリケーションのアーキテクチャは、コードの全体的な「組織」です。さまざまなアーキテクチャの例としては、MVC、MVVM、MVP、nレイヤー（UI-BLL-DAL）などがあります。通常、アーキテクチャは事前に決定する必要があり、アプリケーションを構築した後は変更するのが難しい場合があります。

アーキテクチャー要素は、一般にボックスとして表される、クラスまたはモジュールのコレクションに向かう傾向があります。アーキテクチャに関する図は、見下ろす最高のレベルを表していますが、クラス図は最もアトミックなレベルです。アーキテクチャパターンの目的は、システムの主要部分がどのように組み合わされるか、メッセージとデータがシステムをどのように流れるか、およびその他の構造上の問題を理解することです。アーキテクチャー・パターンは、さまざまなコンポーネント・タイプを利用します。それぞれのコンポーネントは通常、連続的に小さくなるモジュールで構成されています。各コンポーネントは、アーキテクチャ内で責任を負います。デザインパターンは、アプリケーションのより小さな粒子のための低レベルまたはクラスレベルのデザインパターンです。

詳細：https : //www.oreilly.com/ideas/contrasting-architecture-patterns-with-design-patterns

まあ、主な部分については、それは言語の問題です。私の経験によれば、ソフトウェアに関する限り、デザインとアーキテクチャの境界は広い川であり、その幅は水位に起因し、主にマーケティングの季節の影響を受けます。一般に、「設計」という用語は、エンドユーザーに認識されるソフトウェア製品の動作の強力な側面とともに使用されます。一方、「アーキテクチャ」は、ソフトウェアの技術的構造、つまりコンポーネント、ライブラリ、プロトコル、およびソフトウェアの要件を満たすために必要なもの設計。「設計パターン」には2つの役割があります。1つ目は、製品ではなく、（多かれ少なかれ）標準的な問題のカテゴリを解決するためのベストプラクティスと見なされます。2つ目は、開発者のコ​​ミュニケーションを支援することです。シングルトンの例にとどまり、これにより、毎回説明するのではなく、単に単語を使用することで、メカニズムが何であるかを知ることができます。指定されたデータスペース（変数など）を使用して、制御された方法で設定され、唯一の理由は、クラスのコンストラクタなどを保護したためです。したがって、私見の質問に対する短い答えは、誰が話しているかに依存します。それは理にかなっていますか？

設計パターンは、その範囲が建築パターンとは異なり、ローカライズされており、コードベースへの影響が少なく、コードベースの特定のセクションに影響を与えます。次に例を示します。

How to instantiate an object when we only know what type needs to be instantiated at run time (maybe a Factory Class?)
How to make an object behave differently according to its state (maybe a state machine, or a Strategy Pattern?)

アーキテクチャパターンはコードベースに大きな影響を与え、ほとんどの場合、アプリケーション全体に水平方向（つまり、レイヤー内のコードを構造化する方法）または垂直方向（つまり、要求が外部レイヤーから内部レイヤーに処理される方法）に影響しますバック）。アーキテクチャパターンの例：Model-View-Controller、Model-View-ViewModel