ソフトウェアアーキテクチャ-基礎、理論、実践では、両方の定義を見つけることができます。問題は、それぞれが平易な英語で何を意味するのかわからないことです。
アーキテクチャパターンは、問題が発生するさまざまなソフトウェア開発コンテキストを説明するためにパラメータ化された、繰り返し発生する設計問題に適用できる、名前付きのアーキテクチャ設計決定のコレクションです。
建築様式は、（1）特定の開発コンテキストに適用可能であり、（2）そのコンテキスト内の特定のシステムに固有の建築設計決定を制約し、（3）それぞれに有益な品質を引き出す建築設計決定の名前付きコレクションです。結果として生じるシステム。
それぞれが何を意味し、それらの違いは何ですか？
アーキテクチャパターンは、繰り返し発生するアーキテクチャの問題を解決する方法です。たとえば、MVCは、UIをモデルから分離する問題を解決します。Sensor-Controller-Actuatorは、いくつかの入力感覚に直面して作動する問題を解決するのに役立つパターンです。
一方、建築様式は、繰り返される建築設計に付けられた名前にすぎません。パターンとは異なり、問題を「解決」することは存在しません。
Pipe＆filterは特定の問題を解決するのではなく、コードを整理する方法にすぎません。クライアント/サーバー、メインプログラムとサブルーチン、抽象データ型/ OO、同じ。
また、1つのアーキテクチャに複数のアーキテクチャスタイルを含めることができ、各アーキテクチャスタイルで複数のアーキテクチャパターンを利用できます。
率直に言って、私は常にこれらの用語の両方を同義語と見なしてきました。そして、素人（比較的言えば）の文学は間違いなくそれらをそのように扱います。MSDNまたはWikipediaを参照してください
しかし、あなたの質問は私に少し興味をそそられたので、私はもう少し掘り下げて率直に言いました...エンタープライズアーキテクチャの実用ガイド（Coadシリーズ）への参照を除いて、私は多くを見つけることができませんでした。
建築様式（Base et al。1997）と建築パターン（Buschmann et al。1996）は本質的に同義語です。
もう少しグーグルに基づいて、これは私が2つを区別するための1つの可能な方法であるかもしれないと思うものです：
アーキテクチャパターンがデザインパターン、つまりアダプタとどのように異なるか、オブザーバーは基本的に、それらが適用される粒度のレベルによって異なります（これは問題の一部ではないことはわかっていますが、関連していると思います...）
私の見解では、パターンとアーキテクチャ スタイルは、設計の専門知識をカプセル化するための補完的なメカニズムです。アーキテクチャ スタイルは、ビルディング ブロック デザイン要素のコレクション、ビルディング ブロックを構成するためのルールと制約、およびスタイルで作成されたデザインを分析および操作するためのツールを提供します。スタイルは通常、特定のドメインで幅広いクラスのアーキテクチャを構築するためのガイダンスと分析を提供しますが、パターンは特定のスタイル (または複数のスタイル) 内のより小さく、より具体的な問題の解決に焦点を当てています。
アーキテクチャの設計パターンはよりドメイン固有であり、アーキテクチャのスタイルはより一般的で幅広いアプリケーションで使用できます。このため、アーキテクチャ パターンにはより多くのドメイン知識が必要です。
アーキテクチャ パターンについては、GoFで説明されているように、コードをスタイルする具体的な方法を考えてください。アダプター、ストラテジー、ビルダー、メディエーターなど
建築様式については、システム全体を考えてください。IE、プレゼンテーションには MVC を使用し、ビジネス層をモデル化するには DDD を使用し、相互運用には WCF (.NET を使用している場合)、統合には SOA などを使用します。
アーキテクチャ パターン – 要素の種類とその相互作用の一般的なセットを定義します。アーキテクチャ パターンの例には、パイプとフィルター、モデル - ビュー - コントローラー、およびリフレクションが含まれます。
アーキテクチャ スタイル – この用語は Garlan と Shaw によって造られたもので、システム構成の慣用的なパターンです。たとえば、クライアント サーバー システムはアーキテクチャ スタイルです。
ps : オリジナルの建築様式の多くは、パターンとして再構築されています。
アーキテクチャ パターン:コンテキスト + 問題 -> 解決策
アーキテクチャ スタイル:アーキテクチャ パターンのソリューション部分
したがって、アーキテクチャ スタイルは、アーキテクチャ パターンのソリューション部分に類似しています。これは、コンテキストや問題がどのように発生したかではなく、ソリューションに焦点を当てたアーキテクチャ ドキュメントを扱う本でよく使用されます。