他の選択肢 ヘキサゴナルアーキテクチャ
前回はレイヤーアーキテクチャをDIを使用して完全にモデルを他の層から分離することを学びました。
レイヤーとは他の考え方として、層ではなく、外部（ビューやデータベース・アクセス)と内部（モデル）があるだけという考え方があるそうです。
AlistairCokburnのヘキサゴナルアーキテクチャがその考え方の１つです。
ビューやデータベースアクセスなどそれぞれがそれぞれのアダプタを持っていて、各アダプタがアプリケーションの内部に合わせた形式に変換します。
六角形の各辺がポートを表して、入力、または出力に対応しています。
各辺のポートの定義は厳密ではなく、ある一辺は永続化を担当、ある一辺はビューからの入力を担当、またある一辺はメッセージングによる通知を担当などなど。。。
このヘキサゴナルアーキテクチャは最近できた概念ではなく、2004年のPoEAA本に記載されていましたし、2002年ごろには既にWikiにて紹介されていたそうです。(ヘキソゴナルアーキテクチャの日本語訳より)
PoEAAでの紹介では、ヘキソゴナルアーキテクチャを採用する動機として、
レイヤアーキテクチャでは、ユーザーを中心に考えてきたが、実際は他にバッチ処理だったり、Webサービスなど人間を介在しないこともあります。そう見ると、プレゼンテーションレイヤとデータソースレイヤ(インフラストラクチャ)には外部との接続に関するレイヤとして多くの類似点があるようにみえます。
と挙げています。
特に、現在では、非同期メッセージングやRestなど、外部と接触する技術が増えてますので、この考え方は理にかなっているように見えます。
実装
ポートなりアダプタなり実装の仕方はどうするの？という疑問が湧くと思いますが、多分前回とそんなに変わらないです。
アダプタはMVCのコントローラなり、インフラストラクチャのRepository実装だったりでOKだと思います。ポートはビューならSpringなどのフレームワークの仕組みをそのまま利用できるし、DBとの接続用のもMybatisなどの仕組みを使えます。
ファウラーの考え方
ヘキソゴナルアーキテクチャは対称性があるアーキテクチャで、レイヤアーキテクチャは非対称のアーキテクチャと考えられます。
しかし、私はこの非対称性こそ有用だと思っています。他へのサービスとして提供するインターフェイスと、他のサービスを利用することの間には、歴然とした違いがあるからだ。・・・プレゼンテーションは、他者に対してシステムが提供するサービスの外部インターフェースである。・・・データソースは、サービスを提供するものへのインターフェースである。クライアントが異なるとサービスの考え方が変わるので、これらを分けて考えることは有用であると私は考える。(PoEAA第一部レイヤ化 より)
自分もどちらかと言えば、この考え方に賛成です。とは言え、外部との接続技術は増えて整理することが困難になりつつあります。もう少しアーキテクチャについて考えていきたいと思います。
ただ、どんなアーキテクチャもモデルを分離することが一番大事です。