Software Architecture-Foundations、Theory and Practiceでは、両方の定義を見つけることができます。問題は、私がそれらのそれぞれが単純な英語で何を意味するのか理解できないことです:
Architectural Patternは、その問題が発生するさまざまなソフトウェア開発コンテキストを説明するためにパラメーター化された繰り返し発生する設計問題に適用できる、アーキテクチャ設計決定の名前付きコレクションです。
Architectural Styleは、(1)特定の開発コンテキストに適用できる、(2)そのコンテキスト内の特定のシステムに固有のアーキテクチャ設計決定を制約する、および(3)それぞれに有益な品質を引き出す、アーキテクチャ設計決定の名前付きコレクションです。結果のシステム。
それぞれの意味とそれらの違いは何ですか?
建築パターンは、繰り返し発生する建築問題を解決する方法です。たとえば、MVCは、UIをモデルから分離する問題を解決します。 Sensor-Controller-Actuatorは、いくつかの入力感覚に直面して作動する問題に役立つパターンです。
一方、建築スタイルは、現在の建築設計に付けられた名前にすぎません。パターンとは逆に、問題を「解決」することはありません。
Pipe&filterは特定の問題を解決するものではなく、コードを整理するための方法にすぎません。クライアント/サーバー、メインプログラムとサブルーチン、抽象データ型/ OO、同じ。
また、単一のアーキテクチャーに複数のアーキテクチャー・スタイルを含めることができ、各アーキテクチャー・スタイルは複数のアーキテクチャー・パターンを利用できます。
率直に言って、私は常にこれらの両方の用語を同義であると考えてきました!そして、素人の(比較的言えば)文学は間違いなくそれらをそのように扱います。参照 [〜#〜] msdn [〜#〜] または Wikipedia
しかし、あなたの質問は私に少し興味をそそられたので、私はもう少し掘り下げて率直に言った... エンタープライズアーキテクチャの実践ガイド(The Coadシリーズ) への参照を除いて、あまり見つけることができませんでした。引用元:
建築様式(Base et al。1997)と建築様式 (Buschmann et al。1996)は本質的に同義です。
もう少し googling に基づいて、これは2つを区別する1つの可能な方法であると私が思うものです:
アーキテクチャパターンが設計パターンとどのように異なるか、すなわちアダプタ、オブザーバ基本的に、それらが適用される粒度のレベルによって決まります(これは問題の一部ではないことはわかっていますが、関連していると思います...)
建築スタイルは抽象的、つまり概念的です。
+---------------+--------------------------------------------------------+
| Category | Architecture styles |
+---------------+--------------------------------------------------------+
| Communication | SOA, ROA, Message Bus |
| Deployment | Client/Server |
| Domain | Domain Driven Design,Monolithic application |
| Structure | Component-Based, Object-Oriented, Layered, Plug-ins |
+---------------+--------------------------------------------------------+
建築パターンは具体的、つまり建築スタイルの実装です。
設計パターンは、アーキテクチャレベルでソフトウェア設計で一般的に発生する問題に対する一般的な再利用可能なソリューションです。
アナロジー:さまざまな宗教の寺院建築様式:
非常に単純な言葉で:
概念、理論です(そしてそれをどのように実装するかはあなた次第です)。また、ソフトウェアの世界以外にも適用できます。
例:REST( Representational State Transfer )is aarchitectural stylebuilt on some特定現在の「Web」の基礎を使用した原則。
ソフトウェアシステム(またはモジュール)レベルでのソリューションについて説明します。言い換えれば、それが互いにどのように相互作用するか。モデル付きのビュー、およびコントローラー付きのモデル。
コアレベルのソリューションであり、クラス、関数、およびロジックの実際の流れについて説明します。
私の見解では、パターンと建築スタイルは、設計の専門知識をカプセル化するための補完的なメカニズムです。建築スタイルは、ビルディングブロックデザイン要素のコレクション、ビルディングブロックを構成するためのルールと制約、およびスタイルで作成されたデザインを分析および操作するためのツールを提供します。スタイルは一般に、特定のドメインで幅広いクラスのアーキテクチャを構築するためのガイダンスと分析を提供しますが、パターンは、特定のスタイル(またはおそらく複数のスタイル)内のより小さな特定の問題の解決に焦点を当てます。
建築パターンの場合、 GoF のように、コードをスタイルする特定の方法を考えます。アダプター、戦略、ビルダー、メディエーターなど
建築スタイルについては、全体的なシステムを考えてください。つまり、プレゼンテーションにMVCを使用し、ビジネスレイヤーをモデル化するDDD、InteropにWCF(.NETを使用している場合)、統合にSOAなど)を使用します。
建築設計パターンは、ドメインに固有であり、建築スタイルはより汎用的で、幅広いアプリケーションで使用できます。このため、アーキテクチャパターンには、より多くのドメイン知識が必要です。
アーキテクチャスタイルは、アプリケーションサブシステムのより広範な組織を表し、その全体的な概要の概念を表す名前です。例は、SOA
、Client/Server
、Message Bus
など.
アーキテクチャパターンは、一般的なアーキテクチャの問題に対する再利用可能なソリューションの名前であり、それらを解決するために内部パーツがどのように実装されているかを示します。例は、2-Tier
、3-Tier
、N-Tier
、MVC
、REST
など.
1つのスタイルで複数のパターンを使用して、複数の問題を解決できます。たとえば、クライアント/サーバースタイルはN-Tierパターンまたは(および)MVCパターンを使用してビジネスロジック、プレゼンテーションロジック、データロジックmodifiability
およびmaintainability
の問題を解決するモジュール性を導入するため。
アーキテクチャパターン–要素タイプの一般的なセットとそれらの相互作用を定義します。建築パターンの例には、パイプとフィルター、モデル-ビュー-コントローラー、反射が含まれます。
アーキテクチャースタイル–この用語はGarlanとShawによって作成されたもので、システム編成の慣用的なパターンです。たとえば、クライアントサーバーシステムはアーキテクチャスタイルです。
pS:元の建築スタイルの多くはパターンとして再構成されています。
アーキテクチャスタイルは、多くのコンポーネントのシステムを表します。アプリケーションアーキテクチャは1つだけであり、マイクロサービス、SOA、イベント駆動型アーキテクチャなどの1つのアーキテクチャスタイルをあらゆる場所に適用する必要があります。
アーキテクチャパターンは単一のコンポーネント内の何かを記述し、CQRSやDDDなどの同じアーキテクチャパターンをどこにも適用しようとはしません。
アーキテクチャパターン:コンテキスト+問題->ソリューション
アーキテクチャスタイル:アーキテクチャパターンのソリューション部分
したがって、アーキテクチャスタイルは、アーキテクチャパターンのソリューション部分に類似しています。これは、コンテキストと問題がどのように発生したかではなく、ソリューションに焦点が当てられているアーキテクチャのドキュメントを扱っている本でよく使用されます。
アーキテクチャスタイルは、非常に大まかに、コードの編成方法を教えてくれます。これは最高レベルの細分性であり、アプリケーションのレイヤー、高レベルモジュール、およびそれらのモジュールとレイヤーが相互にどのように相互作用するか、それらの間の関係を指定します。建築スタイルの例:コンポーネントベース、SOA
アーキテクチャパターンはコードベースに大きな影響を及ぼし、ほとんどの場合、アプリケーション全体に水平方向(つまり、レイヤー内のコードを構造化する方法)または垂直方向(つまり、要求が外側のレイヤーから内側のレイヤーに処理される方法)に影響します。バック)。アーキテクチャパターンの例:Model-View-Controller、Model-View-ViewModel