ソフトウェア設計とソフトウェアアーキテクチャー
誰かがソフトウェア設計とソフトウェアアーキテクチャの違いを説明できますか？
すなわち;あなたが誰かにあなたに「デザイン」を提示するように言うならば - あなたは彼らが何を提示すると期待しますか？建築についても同様です。
私の現在の理解は：
- 設計：特定のモジュール/システムの一部のためのUML図/フローチャート/単純なワイヤーフレーム（UI用）
- アーキテクチャー：コンポーネント図（システムのさまざまなモジュールが他のシステムとどのように通信するかを示す）、使用される言語、パターンなど
私が間違っていたら私を直してください。私はウィキペディアに http://en.wikipedia.org/wiki/Software_design および http://en.wikipedia.org/wiki/Software_architecture に関する記事がありますが、正しく理解したかどうかはわかりません。
その通りです。システムのアーキテクチャはその「スケルトン」です。これはシステムの最高レベルの抽象化です。どのような種類のデータストレージが存在するか、モジュールは互いにどのようにやり取りするか、どのようなリカバリシステムが用意されているか。デザインパターンと同じように、アーキテクチャパターンがあります：MVC、3層レイヤードデザインなど。
ソフトウェア設計は、個々のモジュール/コンポーネントを設計することです。モジュールxの責任、機能は何ですか？クラスYの？それは何ができ、何ができませんか？どのようなデザインパターンが使えますか？
つまり、ソフトウェアアーキテクチャはモジュール/コンポーネント/クラスレベルを重視しているのに対し、ソフトウェアアーキテクチャはシステム全体の設計に関するものです。
SDLC（Software Development Life Cycle） のいくつかの説明では、それらは互換性がありますが、コンセンサスはそれらが異なるということです。同時に：異なる（1）ステージ、（2）責任範囲、および（3）意思決定のレベル。
- アーキテクチャ は全体像です：フレームワーク、言語、スコープ、目標、および高度な方法論の選択（ Rational 、 waterfall 、- アジャイル など）。
- デザイン は小さい図です。コードの編成方法の計画。システムの異なる部分間の契約がどのように見えるか。プロジェクトの方法論と目標の継続的な実装。仕様はこの段階で作成されます。
これらの2つのステージは、さまざまな理由でブレンドします。
- 多くの場合、小規模なプロジェクトには、計画を段階ごとに分けるのに十分な範囲がありません。
- プロジェクトはより大きなプロジェクトの一部である可能性があるため、両方の段階の一部はすでに決定されています。 （既存のデータベース、規約、標準、プロトコル、フレームワーク、再利用可能なコードなどが既に存在します。）
- SDLCについての新しい考え方（ アジャイル手法 を参照）は、この従来のアプローチをいくらか再配置します。 SDLC全体を通して、意図的に（より少ない範囲でのアーキテクチャ）が行われます。多くの場合、プロセス全体が何度も繰り返される 繰り返し があります。
- とにかくソフトウェア開発は複雑で計画するのは困難ですが、クライアント/マネージャー/営業担当者は通常、目標と要件を途中で変更することにより難しくします。それが計画であるかどうかに関係なく、プロジェクトの後半で設計およびアーキテクチャの決定を行う必要があります。
責任の段階または領域が混ざり合って、あちこちで起こったとしても、どのレベルの意思決定が起こっているかを知ることは常に良いことです。 （私たちはこれをいつまでも続けることができます。要約していきたいと思います。）で終わります：あなたのプロジェクトに正式な建築または設計段階/ AOR /ドキュメントがない場合でも、IS誰かが意識的にそれをやっているかどうかにかかわらず起こります。誰もアーキテクチャーを実行することを決定しない場合、おそらく貧弱なデフォルトが発生します。デザインにも同じ。これらの概念は、それらを表す正式な段階がない場合、ほとんどより重要です。
設計は戦術的ですが、建築は戦略的です。
アーキテクチャは、フレームワーク、ツール、プログラミングパラダイム、コンポーネントベースのソフトウェアエンジニアリング標準、高レベルの原則で構成されています。
デザインは、デザインパターン、プログラミングの慣用句、リファクタリングなど、地域の制約に関わる活動です。
私は自分が建築とデザインの単純な違いを探していたときにこれを発見しました。
この見方についてどう思いますか。
- 建築は私たちが構築している「もの」です。
- デザインは私たちが構築している「方法」です。
アーキテクチャとは、コンピュータまたはコンピュータベースのシステムの概念的な構造および論理的な構成を意味します。
デザインとは、システムやオブジェクトを作成する前にその外観や機能または動作を示すために作成された計画または図面のことです。
コンポーネントを「設計」している場合は、大規模システムにおけるコンポーネントの動作を定義しています。
同じコンポーネントを「設計」している場合は、それが内部的にどのように動作するかを定義しています。
すべての建築はデザインですが、すべての設計がアーキテクチャーではありません。
Whatの部分はデザイン、Howは具象実装、そしてWhatとHowの共通部分はアーキテクチャーです。
建築とデザインを区別するための画像：
アーキテクチャ的に重要ではない、すなわち設計のアーキテクチャブランチに属さない設計決定もある。たとえば、アルゴリズムの選択、データ構造の選択など、一部のコンポーネントの内部設計に関する決定.
コンポーネントの境界を超えて見えない設計上の決定は、コンポーネントの内部設計であり、非アーキテクチャ的なものです。これらは、システム設計者がシステムレベルアーキテクチャによって課されるアーキテクチャ上の制約を超えない限り、システム設計者がモジュール設計者の裁量または実装チームに任せる設計上の決定です。
を与えるリンク 良いアナロジー
私は自分の言葉で、あなたは正しいと言うでしょう。
アーキテクチャは、システム要件へのシステム要件の割り当てです。アーキテクチャに関する4つのステートメント
- それは言語やパターンのような機能的でない要件を導入することがあります。
- コンポーネント間の相互作用、インタフェース、タイミングなどを定義します。
- 新しい機能は導入されません。
- システムが実行しようとしている（設計された）機能を要素に割り当てます。
システムの複雑さが細分化されている場合、アーキテクチャーは必須のエンジニアリングステップです。
例：あなたの家について考える、あなたはあなたの台所のための建築家（1つの要素だけが関係する）を必要としません、しかし完全な建物はドアと屋根のようないくつかの相互作用定義を必要とします。
設計は、（提案された）関数の実装の有益な表現です。それはフィードバックを引き出し、ステークホルダーと話し合うことを目的としています。それは良い習慣かもしれませんがこれは重要な技術的ステップではありません。
キッチンを設置する前にキッチンのデザインを見てみるのはいいでしょうが、調理の要件には不可欠ではありません。
私がそれについて考えるなら、あなたは述べることができます：
- アーキテクチャは、より詳細な抽象化レベルの一般/エンジニア向けです。
- デザインはそれほど詳細ではない抽象化レベルでの公衆向けです。
私の注意：
- 誰かに尋ねることなくデザインを変更することができます
- アーキテクチャを変更した場合は、それを他の人（チーム、クライアント、利害関係者など）に伝える必要があります。
私たちはデザイン対アーキテクチャについて話す時を決定するために次の規則を使うべきだと思います。
たとえば、クラス図やシーケンス図が表示されている場合は、クラス構文構造を使用してクラスとその関係をオブジェクト指向プログラミング言語にマップできます。これは明らかにデザインです。さらに、これは、この説明がソフトウェアシステムの実装に使用するプログラミング言語と関係があることを示している可能性があります。 Javaを使用する場合は、Javaがオブジェクト指向プログラミング言語であるため、前の例が適用されます。パッケージとその依存関係を示す図が出てきたら、それもデザインです。要素（この場合はパッケージ）をJavaの構文構造にマップできます。
ここで、Javaアプリケーションがモジュールに分割されていて、各モジュールが一連のパッケージ（jarファイル展開単位として表される）であるとします。モジュールとその依存関係を含む図が表示されます。 Java（少なくともJava 7まで）では、モジュール（一連のパッケージ）を構文構造にマッピングする方法はありません。また、この図がソフトウェアモデルの抽象化レベルにおける一段高いレベルを表していることに気付くかもしれません。パッケージ図より上の（より粗い）図は、Javaプログラミング言語で開発したときのアーキテクチャー図を表しています。一方、Modula-2で開発している場合、モジュール図はデザインを表します。
（ http://www.copypasteisforword.com/notes/software-architecture-vs-software-designからの断片 ）
個人的には、私はこれが好きです：
「設計者は、ユーザーがボタンを押したときの動作に関心があり、設計者は、1万人のユーザーがボタンを押したときの動作に関心があります。」
SCEA for Java™EE研究ガイド Mark CadeおよびHumphrey Sheil著
私は多くの説明に同意します。基本的に私たちはアーキテクチャ設計とソフトウェアシステムの詳細設計の違いを認識しています。
設計者の目標は、開発に必要となるのと同じくらい正確かつ具体的になることです。アーキテクトは基本的にシステムの構造とグローバルな振る舞いを詳細設計に必要なだけ指定することを目的としています。
優れたアーキテクトは、ハイパースペックを防ぎます。アーキテクチャーは過度に指定されてはいけませんが、処理するのが最もコストのかかるリスクを提示する側面に対してのみ確立されたアーキテクチャー決定です。詳細な設計、すなわち局所的な機能性の多様性に基づいて設計することができる。
実際、アーキテクチャープロセスまたはライフサイクルは、このテーマ、つまり（アーキテクチャー上）重要なビジネス要件のための構造を概説するための適切なレベルの抽象化、およびより具体的な成果物のための設計フェーズへの詳細な説明に従います。
建築はデザインですが、すべてのデザインが建築的というわけではありません。 したがって、厳密に言えば、architecture designとnon-architectural designを区別することをお勧めします。そして違いは何ですか？場合によります！各ソフトウェア設計者は異なる答えを持つかもしれません（ymmv！）。私たちは、「クラス図はアーキテクチャ、シーケンス図はデザイン」という答えを出すための発見的方法を開発します。詳しくは DSA book をご覧ください。
アーキテクチャーはデザインよりも抽象化レベルが高い、またはアーキテクチャーは論理的でデザインは物理的であると言うのは一般的です。しかし、この概念は、一般的に受け入れられていますが、実際には無用です。高い抽象度と低い抽象度の間、論理的なものと物理的なものの間のどこに線を引きますか。場合によります！
だから、私の提案は：
- 単一のデザイン文書を作成します。
- この設計書にあなたが望むやり方、あるいはもっと読者の慣れ親しんだやり方で名前をつける。例：「ソフトウェアアーキテクチャ」、「ソフトウェア設計仕様」。
- この文書を複数のビューに分割して、別のビューの改良版としてビューを作成できることに注意してください。
- 相互参照またはハイパーリンクを追加して文書内のビューをナビゲート可能にする
- そうすると、デザインの全体像は浅いが概観を示す高レベルのビューと、狭く深いデザインの詳細を示す実装に近いビューが表示されます。
- あなたはマルチビューアーキテクチャドキュメントの例を見たいと思うかもしれません（ here ）。
それをすべて言った… 私達が尋ねる必要があるより関連した質問は：どれくらいのデザインが十分であるか？ それは、いつ私はデザインを説明するのをやめて（図表や散文で）、コーディングに移るべきですか？
良い質問...両者の間の線が明瞭な線になることはほとんどありませんが、両方の用語を使用している場合、Architectureは何かを構築または構築する方法に関するより技術的または構造的な決定を含みます。一方、Designは後で変更が容易な決定（メソッド名、クラスのファイル構造、デザインパターンなど）を含み、シングルトンを使用するか静的クラスを使用して特定の問題を解決するかを決定します。および/またはシステムまたはアプリケーションの外観または審美的側面に影響を与えるもの（ヒューマンインターフェイス、使いやすさ、外観など）
うん、それは私には聞こえます。デザインはあなたがやろうとしていることであり、アーキテクチャはデザインの細部と部分が一緒に結合される方法です。それは言語にとらわれないかもしれませんが、通常使用される技術、すなわちLAMP v Windows、Webサービスv RPCを指定するでしょう。
プログラムまたはコンピューティングシステムのソフトウェアアーキテクチャは、ソフトウェアコンポーネント、それらのコンポーネントの外部から見える特性、およびそれらの間の関係を含むシステムの構造または複数の構造である。
（ウィキペディアより http://en.wikipedia.org/wiki/Software_architecture ）
ソフトウェア設計は、ソフトウェアソリューションの問題解決と計画のプロセスです。ソフトウェアの目的と仕様が決まったら、ソフトウェア開発者は設計者を使ってソリューションの計画を立てます。それはアーキテクチャの見解と同様に低レベルのコンポーネントとアルゴリズム実装問題を含みます。
（ウィキペディアより http://en.wikipedia.org/wiki/Software_design ）
自分で言ったことができませんでした:)
私はPatrick Karcherと同じように建築を見ています - 全体像。たとえば、建築物を建築物に提供したり、その構造的なサポート、窓、出入り口、排水などを表示したりすることができます。しかし、床のレイアウトやキュービクルの位置などを「設計」したことはありません。
建物を設計している間は、各オフィスのレイアウトを設計していません。ソフトウェアについても同じことが言えます。
しかし、レイアウトの設計は、「レイアウトの設計」と見なすことができます。
かなり主観的だが私の考え：
アーキテクチャ他のシステムとの相互作用、ハードウェア要件、全体的なコンポーネント設計、およびデータフローを含むシステムの全体的な設計。
設計システム全体におけるコンポーネントの構成と流れ。これには、他のコンポーネントと対話するためのコンポーネントのAPIも含まれます。
ソフトウェアアーキテクチャは、「計算のアルゴリズムやデータ構造を超えて、問題に関心を持っています...」です。
アーキテクチャは、具体的には…実装の詳細（アルゴリズムやデータ構造など）ではありません。アーキテクチャ設計では、通常はOOD（オブジェクト指向設計）で提供されるものよりも豊富な抽象概念の集まりが必要です。
Designは、設計要素のモジュール化と詳細なインタフェース、それらのアルゴリズムと手続き、そしてアーキテクチャをサポートし、それを満足させるのに必要なデータ型と関係があります。必要条件.
「アーキテクチャー」は、「デザイン」の単なる同義語として使用されることがよくあります（形容詞の「高レベル」が前に付いている場合があります）。そして多くの人々は、「デザインパターン」の同義語として「建築パターン」という用語を使用しています。
このリンクをチェックしてください。
...遠い昔、遠く離れた場所で、哲学者たちは1人と多くの人の区別を心配していました。建築は人間関係についてであり、それは多くを必要とします。アーキテクチャーにはコンポーネントがあります。デザインはコンテンツに関するもので、それはそれを必要とします。デザインには特性、品質、特性があります。私たちは通常、デザインはアーキテクチャの中にあると考えています。二元論的思考は原始的なものとして多くを与えます。しかし建築もデザインの範囲内です。それが私たちが私たちの前にあるものを見ることを選択するすべてのものです - 一つまたは多く。
Architecture：
構造設計は、システムに技術的に重要な要件を実現する、より高い抽象レベルで機能します。建築はさらなる設計のための基礎を築く。
デザイン：
抽象化の各層でアーキテクチャが反復プロセスを通して行わないことを満たす技術。
設計からアーキテクチャを分離する際の経験則として、この論文が本当に好きでした。
http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
これは「内包/局所性」仮説と呼ばれます。ソフトウェアの性質に関する、ローカルではなく意図的なステートメントはアーキテクチャ上のものです。ローカルで意図的なステートメントはデザインです。
誰かが船を建造するなら、エンジン、船体、電気回路などが彼の「建築要素」になるでしょう。彼にとって、エンジン構築は「デザインワーク」になるでしょう。
彼がそれから別のチームにエンジンの建設を委任するならば、彼らは「エンジンアーキテクチャ」をつくります...
つまり、抽象化のレベルや詳細によって異なります。ある人の建築は他の人の設計かもしれません！
アーキテクチャは"変更が難しい設計上の決定事項"
TDDを使用した結果、実際には常にデザインが変更されることになりましたが、私はこの問題に苦労していることがよくあります。上記の定義は、Martin Fowler著のエンタープライズアプリケーションアーキテクチャのパターンから抽出されます。
それはアーキテクチャがあなたのシステムの言語、フレームワークそしてドメインに依存することを意味します。あなたが5分であなたのJavaクラスからインタフェースを抽出することができるだけであれば、それはもはやアーキテクチャ決定ではありません。
ソフトウェアアーキテクチャは、ビジネスや機能をより高いアーキテクチャレベルで識別してアプリケーションに投影する必要がある場合に、システムレベルで最もよく使用されます。
例えば、あなたのビジネスはトレーダーのための「損益」であり、あなたの主な機能は「ポートフォリオ評価」と「リスク計算」を含みます。
しかし、 Software Architect が彼の解決策を詳しく説明するとき、彼はそれを理解するでしょう：
「ポートフォリオ評価」は一つのアプリケーションにはなり得ません。それは管理可能なプロジェクトで洗練される必要があります：
- GUI
- ランチャー
- ディスパッチャ
- ...
（関連する操作が非常に大きいため、共通のGUIで常に監視しながら、複数のコンピュータに分割する必要があります）
ソフトウェア設計では、さまざまなアプリケーション、それらの技術的関係、およびそれらの内部サブコンポーネントを調べます。
最後のアーキテクチャ層（「テクニカルアーキテクチャ」）が機能するのに必要な仕様を生成します。 （技術的枠組みや横断的要素の観点から）、そしてプロジェクトチーム（よりビジネス機能の実装に重点を置いている）のために、それぞれのプロジェクトを始めること。
ソフトウェア設計には長い歴史がありますが、ソフトウェアアーキテクチャという用語はほとんど20年前のものです。したがって、それは今苦痛の増大を経験しています。
学者は、アーキテクチャをソフトウェア設計のより広い分野の一部と見なす傾向があります。 Archはそれ自身の中の分野であるという認識が高まっていますが。
実務家は、Archを戦略的であり、元に戻すにはプロジェクトにコストがかかる可能性がある高レベルの設計決定と見なす傾向があります。
Archとデザインの間の正確な境界はソフトウェアドメインによって異なります。たとえば、Webアプリケーションの分野では、階層アーキテクチャが現在最も普及しています（Biz Logic層、Data Access Layerなど）。このArchの下位レベルの部分は設計（クラス図、メソッドシグネチャなど）と見なされます。 ）これは、組み込みシステム、オペレーティングシステム、コンパイラなどの分野では異なる定義になります。
クリフノーツのバージョン：
設計：目的の製品の仕様に基づいてソリューションを実装する。
アーキテクチャ：あなたのデザインをサポートする基盤/ツール/インフラストラクチャ/コンポーネント。
これはかなり広範な質問ですが、多くの回答が寄せられます。
アーキテクチャーは、システムを構築するためのデザインパターンの集まりです。
私は、デザインがこれらすべてをまとめるために使用された創造性であると思いますか？
私の論文の中でRoy Thomas Fieldingによるソフトウェアアーキテクチャとは何かについての定義と説明が好きです。 建築スタイルとネットワークベースのソフトウェアアーキテクチャの設計
ソフトウェアアーキテクチャは、ソフトウェアシステムの動作のある段階におけるランタイムの要素を抽象化したものです。システムは、それぞれ独自のソフトウェアアーキテクチャを持つ、さまざまなレベルの抽象化とさまざまな操作フェーズで構成されます。
彼は「ランタイム要素」と「抽象化レベル」を強調しています。
建築とデザインは密接に関連しています。それらの間の主な違いは本当に私たちが直面している方法についてです。建築は戦略、構造および目的に向けて、抽象的に向けられている。デザインは、具体化に向けて、実装と実践に向けられています。
これに対する明確な答えはありません。なぜなら、「ソフトウェアアーキテクチャ」と「ソフトウェアデザイン」にはかなりの数の定義があり、どちらにも標準的な定義がないからです。
その良い考え方は、Len Bass、Paul Clements、Rick Kazmanの「すべてのアーキテクチャはデザインであり、すべてのアーキテクチャがアーキテクチャではない」という声明です。私は（アーキテクチャが他のアクティビティを含むことができるので）私がそれに全く同意しないかと思いますが、それはアーキテクチャがデザインの重要な部分集合を扱うデザインアクティビティであるという本質を捉えます。
私のやや派手な定義（ SEI定義ページ にあります）は、それが誤った決定をした場合にあなたのプロジェクトがキャンセルされる原因となる一連の決定事項です。
概念としてアーキテクチャ、設計、および実装を分離することにおける有用な試みは、数年前にここで見つけることができる「アーキテクチャ、設計、実装」と題された研究論文で行われました。 http：// www .sei.cmu.edu/library/assets/ICSE03-1.pdf 彼らの言語は非常に抽象的ですが、単純化して言うと、アーキテクチャーは多くのコンテキストで使用できる設計であり、システム全体に適用することを意図しています。設計は多くの文脈で使用することができるがシステムの特定の部分に適用される（err）設計であり、実装は文脈に固有の設計であり適用されるその文脈で。
つまり、アーキテクチャー上の決定はRPCではなくメッセージングを介してシステムを統合するという決定になる可能性があるため（多くの場所で適用でき、システム全体に適用することを意図している一般原則）、設計決定はマスターを使用することです。システムの入力要求処理モジュール内の/スレーブスレッド構造（この場合はただ1つのモジュール内で使用される可能性がある一般的な原則）と最後に、実装の決定は要求ルーターからセキュリティに対する責任を移動することです。 Request Managerモジュール内のRequest Handler（そのコンテキストにのみ関連する、そのコンテキストで使用される決定）へ。
これが役に立つことを願っています！
Design：モジュール、モジュール間のどのような関係、各モジュールの機能、クラスとそのメンバー関数、お互いに通信する各モジュールのインターフェースについて学ぶ。
Architecture：アーキテクチャはソフトウェアシステムの全体構造です。すべてのモジュール、クラス、およびコンポーネントは異なるタスクを実行し、独自の結果をもたらします。
例：5つの部屋がある家があります。付属のバスルームもあります。キッチンも家の中にあります。だから家には違うものがあり、これらすべてがお互いに異なる関係を持っています。だから、これは家の「デザイン」についてのすべてです。
あなたが家の外から見ているときあなたが見ている全体の構造はすべて建築についてです。
アーキテクチャはハイレベル、抽象的、論理的デザインであり、ソフトウェアデザインはローレベル、詳細かつ物理的デザインです。
アーキテクチャーは、スケーラビリティーなどの非機能的要件が最も重要であり、経験が最も重要ではないというさまざまな要因から来る理論的根拠を持つ設計です。理論的根拠がなければ、あなたは明白なパターンややり方で任されています。より高いレベルで設計するかクラスレベルで設計するかにかかわらず、それはまだ設計です。
または別の言い方をすると
建築はメタデザイン、すなわちデザインをデザインすることです。特定の解空間に適合することが知られているパターンがいくつかありますが、どれを選択しますか、またその理由は何ですか。建築はあなたが "which"と "why"に答えるときです（ "how"はすでに設計によって与えられています）。それは確かに抽象化のレベルには依存しません。例えば、分散セッションの実装はクラスレベルのタスクではありませんが、与えられたアーキテクチャに対して選択するべきいくつかのデザインがあります。
同様に、アーキテクチャはクラスレベルの設計にも反映されます。スケーラブルアーキテクチャの下では、スケーラビリティファクタを考慮せずにクラス設計を行う場合、クラス設計は異なることがよくあります。なぜ "BeginAsyncUpload"と "Upload"のどちらのメソッドを使用する必要があるのかは、アーキテクチャ上の決定です。
興味深いことに、我々がより高いレベルでシステム要素に焦点を合わせるにつれて、「それはなぜ」という質問がより重要になり、「どのように」関連性が低くなるかという疑問に直面する。また、繰り返し使用すると、例えばAbstract FactoryとPrototypeのどちらを選択するかが明らかになるため、「how」部分がより重要になります。
私の意見では、建築はビジョン、要求を集め、正しい方法で構成要素を組み立てることに他ならない
設計として、特定のブロックを構築するために100の解決策があるかもしれませんが、正確な要件を満たすためには正しい方法を選択する必要があるので、正しい方法またはアルゴリズムを選択することは設計に他なりません
アーキテクチャーは、システムのさまざまな機能を統合してシステム全体の1つの目標を達成しながら、設計が各機能要件を満たすようなものです。
たとえば、アーキテクチャパターンであるMVVMの例を取ります。通知機能のために、MVVMはオブザーバパターンを使用します。これは設計パターンです。
他にも指摘されているように、ソフトウェアのアーキテクチャをレイアウトすることは実際にはソフトウェア開発や実行ライフサイクルに全体的な影響を与える主要な設計上の決定を取っています。とても単純化してアーキテクチャは単なるハイレベル設計です。
アーキテクチャーの決定がすべてのコンポーネントに影響を与えるわけではない（つまりローカルである）場合でも、グローバルに関連性があるはずです。つまり、何らかの形でシステム全体に影響を与えます。それ以外の場合は、単にローカルの設計上の決定です。
私が指摘したいのは、アーキテクチャに関するより関連性のある質問は、コンピュータアーキテクチャのHennessy＆Pattersonによって定義されているような、アーキテクチャと組織の関係でしょう。これに基づいて、実装（ソフトウェア開発）プロセス中に行われる典型的な設計上の決定として、システムと組織のデータモデル（入力/出力、状態）抽象化としてアーキテクチャを考えることができます。
アーキテクチャー： - アーキテクチャーは、仕様に従って、構成のさまざまな段階で計画レイアウトを作成します。
DESINER： - デザイナーは、機能的、美観的、レイアウトへの配慮を持って、考古学計画の基本的な要求をすべて満たすという活動です。
私は、建築は人間やシステムとのインターフェースに関するものだと思います。厄介なことに、プロトコルなどを含むWebサービス契約はアーキテクチャです。色などではなく、画面がどのように構成されているのかというのはアーキテクチャです。
デザインとは何かを構築する方法です。どのようなフレームワーク、言語、テクノロジなどこれはもちろん、企業のガイドラインやプラットフォーム、セキュリティなどを考慮した制限と一致している必要があります。
アーキテクチャーは、システムの基本的なコンポーネントを識別し、それらの構成と、それらがシステムのフレームワークを作成するためにどのように関連しているかを説明します。
設計では、さまざまなコンポーネントと、システムアーキテクチャによって提供されるフレームワークで必要な機能を提供するためにそれらをどのように開発する必要があるかについて説明します。
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
アーキテクチャはあなたのシステムがどのようにレイアウトされているかを教えてくれます。 1つの伝統的な建築パターンの例は、あなたのシステムがプレゼンテーション、ビジネス、そしてデータ層に分割される3層システムです。
ドメイン駆動設計は4層アーキテクチャを促進します。プレゼンテーション、アプリケーション、ドメイン、およびインフラストラクチャの各層。また、リポジトリパターンはドメイン層とインフラストラクチャ層の間にあります。ドメインモデルはインフラストラクチャについて何も知らないようにし、また純粋で独立性を保つようにする必要があります。そのため、これら2つの層を仲介するためのリポジトリがあります。
リポジトリパターンは再利用可能なソリューションであり、繰り返される問題を処理するので、依然としてパターンです。ただし、リポジトリのパターンは、アーキテクチャについて説明したときにのみ関連性があります。それは、ドメイン駆動設計アーキテクチャにおいてその役割と責任を担っています。システムのどこにでも適用できる抽象ファクトリパターンのような数学的なタイプの一般的な解決策ではありません。