パターンエンタープライズアプリケーションアーキテクチャのパターンで

Question

、Martin Fowler氏は書いている：

をこの本は、あなたが層にエンタープライズアプリケーション を分解 方法について、どのようにこれらの層が一緒に を働くことです。ほとんどの重要でない企業 アプリケーションは何らかの形式の階層化された アーキテクチャを使用しますが、 状況では、 パイプやフィルタなどの他のアプローチが有用です。私は が の層状構造の文脈に焦点を当てているのではなく、そのような状況には入っていません。 が最も広く使われています。

アプリケーションの非階層化アプリケーション/部分を構築するためのパターンはありますか？金融機関の統計モデリングエンジンを使用します。データアクセス用のレイヤーがあるかもしれませんが、ほとんどのコードは単一のレイヤーになると思います。あなたはまだこのような層にGang of Fourのパターンがあると期待しますか？ドメインモデルはどうですか？あなたはOOをまったく使用しますか、それとも純粋に機能的でしょうか？

引用符には、レイヤーの代替モデルとしてのパイプとフィルターが記載されています。データ処理を細分化する方法として、パイプを使ったエンジンを簡単に想像することができます。他にどんなパターンがありますか？タスクのスケジューリング、結果の集計、または作業の配布などの領域に共通のパターンがありますか？ MapReduceの代替手段は何ですか？

Answer 1

ファウラーが意味することは、レイヤードアプリケーションではレイヤ間の "垂直"デカップル通信を構成することに焦点を当てていると思います。

もう1つのアーキテクチャはSOA（サービス指向）です。このアーキテクチャでは、コンポーネント間の「水平」分離された通信を構成することに重点を置いています。 （コンポーネント内では、どちらのモデルも使用できます）。これは新しいことではない。この水平パターンの他のインスタンスは、COM/COM +、CORBA、ワークフロー、そして今や「メッセージング」アーキテクチャまたはESBアーキテクチャです。