本記事では、Model-view-controllerなどに代表されるアーキテクチャを9個紹介します。

はじめに

ソフトウェア開発において、既存の設計を知っておくことはとても重要です。
なかなか開発をしていて、ゼロからいきなり素晴らしい設計を思いつくことはありません。

このため、事前に基本となる設計を知っておき、これらを日々の開発に生かすことで保守性の高いシステムを作り上げることができます。

本記事では設計指針となる歴史あるソフトウェアアーキテクチャをご紹介します。
そして、ソフトウェア開発において何を考え、どのように関心事を分離するかの一助になれば幸いです。
また本記事で紹介するアーキテクチャを以下の書籍で詳細に解説されています。
興味がある型はご一読ください。

レイヤードアーキテクチャ

レイヤードアーキテクチャ最も基本的なアーキテクチャと言えます。

設計指針は関心事の分離と依存方向の制御となります。
それぞれの階層にコードをまとめ、依存関係を管理することで循環参照など変更容易性を低下させる要因を排除しようという意図があります。

クライアントサーバーモデル

Webを実現するアーキテクチャであるクライアントサーバーモデルです。
集中的に特定の役割を担当しているサーバーと、サーバーに要求する1つ以上のクライアントで構成されます。

クライアントはサーバーに要求(リクエスト)し、サーバーはクライアントに応答(レスポンス)することで処理が進んでいきます。
特徴として、サーバーとクライアントは一対多の関係にある点です。

マスタースレーブ

さきほどのクライアントサーバーと矢印の向きが逆になっていることにご注意ください。
マスタースレーブは、マスターが常にスレーブを制御し処理を分散します。

クライアントサーバーとは起点が逆向きとなり、マスターが常に処理の起点となりスレーブに処理を命令します。

代表例としてはコンピュータシステムです。コンピュータシステムにおいては、CPUがマスターとなり、周辺機器がスレーブとなります。

パイプ&フィルター

パイプ&フィルター(Pipes and Filter)パターンはデータをストリームとして扱うシステムのためのアーキテクチャパターンです。

Linuxを使う方にとってはなじみの深いアーキテクチャかと思います。

それぞれの処理ステップをフィルターにカプセル化し、フィルター間はパイプを介して引き渡します。
フィルターにカプセル化した処理は他の処理に入れ替える・並べ替えることができます。

この柔軟性により、類似する一連のシステムを構成します。

ブローカーパターン

分散ソフトウェアシステムのためのアーキテクチャパターンです。
互いに依存性を持たないコンポーネント群が、リモートサービス呼び出しによって相互に連携します。
ブローカーは、コンポーネント間の相互連携の調整を行います。

サーバーはブローカーにサービスを公開し、クライアントはブローカーを介してサーバーのサービスを要求します。

ピアツーピア

近年ビットコインなどで目にすることが増えたアーキテクチャですね。

ピアツーピアは、ピアと呼ばれるコンポーネントが、
他のピアにサービスを要求するクライアントとしても、他のピアにサービスを提供するサーバーとしても機能します。
各ピアがクライアント、サーバーの役割を動的に変更する点が特徴です。

イベントバスパターン

イベントバスはイベント駆動のアーキテクチャパターンです。
ソースはイベントバスの特定のチャンネルにメッセージを公開します。リスナーは特定チャンネルをサブスクライブします。

Androidのアプリケーション間の連携などに活用されています。

モデルビューコントローラ

Webアプリケーションで用いられることの多いモデルビューコントローラー(MVC)モデルは、 この中で最も有名なアーキテクチャパターンかもしれません。
表示を責務とするView、入力を伝達するController、ドメインロジックのModelを分離し保守性を向上させる狙いがあります。

多くのアーキテクチャに共通する設計指針ですが、Viewの分離は多くのアーキテクチャに用いられる概念ですね。
それほどViewの変更は多く、且つ、Viewの変更を他のモジュールに影響させたくないということですね。

ブラックボードパターン

ブラックボードパターンは、明確な解決戦略が知られていないシステムに適用されることが多いアーキテクチャです。

技術が成熟していない問題に対して、近似的あるいは、妥当な解を求めるアーキテクチャあり、
BlackboardはKnowleadgeSourceに対して、インターフェースを提供しControllerに対して構造化されたオブジェクトを提供します。
KnowleadgeSourceには、問題解決のための様々な手法が独立して存在しています。独立したサブモジュールはそれぞれが連携を取ることはなくBlackboardを介してのみやり取りします。
ControllerはBlackboardを変化に応じて、次のアクションを決定します。
一番イメージの付きにくいアーキテクチャかもしれません。

大雑把なイメージとしてはKnowleadgeSourceは、専門家の集合体です。
そして専門家は技術の進歩に伴い定期的に入れ替わる可能性があります。このため専門家たちは離れがたくなることを避け、それぞれは直接コミュニケーションを取りません。
そして指揮官であるControllerの指揮の元、Blackboardに記載された問題の解決を図ります。
この時呼び出される専門家は問題の全てを解決するわけではなく途中まで解決する場合もあります。
その際はBlackboardに書き残された途中までの解を見てまた、別の専門家が続きから解決に努めます。

このようにブラックボードパターンは、明確な解のない問題に対して様々な手法を組み合わせ解決を図るシステム構築に用いられます。

まとめ

本記事では、様々なアーキテクチャを計9個紹介させて頂きました。
ソフトウェア設計において、言葉だけでも知っていることは非常に重要です。

自分自身が開発に携わるとき、これらの言葉を知っており、深く調べることができ応用することができれば、非常に開発を楽にしてくれるかもしれません。逆に言葉も概念も知らないことは調べることさえもできません。

また、これらのアーキテクチャはメリットがある反面デメリットも存在します。
このため、様々な開発現場に置いて、これらのアーキテクチャに完全に沿って開発することが正解ではない場合もあります。
その際には様々な応用を試みることをお勧めします。
MVCモデルのデメリットを解消するためにMVVMモデルが提唱されたように新たなアーキテクチャパターンの発見につながるかもしれません。