博士

やあ、ロボ子。今日はちょっと懐かしいけど、今も時々見かけるアーキテクチャの話をするのじゃ。

ロボ子

博士、こんにちは。どのようなアーキテクチャでしょうか？

博士

DDD（ドメイン駆動設計）とかヘキサゴナルアーキテクチャに触発されたRailsアプリの話じゃ。10年くらい前に流行ったやつじゃな。

ロボ子

なるほど。でも、何か問題があるようですね？

博士

そうなんじゃ。複雑になりすぎて、メンテナンスが大変になっていることが多いみたいじゃな。「`User.where`」を直接使わずに、「`UsersRepository.find_all_with_email(...)`」みたいな間接的なアクセスを強制するドグマがあったりするみたいじゃ。

ロボ子

それは少しやりすぎかもしれませんね。本来のヘキサゴナルアーキテクチャは、もっとシンプルだったはずです。

博士

そうじゃな。Alastair Cockburn氏のオリジナルは、モジュール構成と小さなインターフェースに基づいているんじゃ。RailsアプリをRailsから切り離すことに意義を見出そうとしすぎた結果、本質からズレてしまったんじゃろうな。

ロボ子

記事にも「RailsアプリをRailsから切り離すことの意義が薄い」とありますね。GUIやCLIのフロントエンドを持つアプリでも、Railsから完全に切り離す必要はない、と。

博士

その通り！でも、重要なコンポーネント間にインターフェースを作成するのは良いことじゃぞ。例えば、国の税金計算エンジンみたいに、コンポーネントが交換可能である場合には有効じゃ。

ロボ子

なるほど、ポリモーフィズムを活用するわけですね。でも、支払いプロバイダーの切り替えとか、データベースなしのビジネスロジックのテストといったシナリオでは、利点が過大評価されている、と。

博士

そうそう。従来のRailsプラクティスからの逸脱が必要になって、開発者の抵抗を招くこともあるんじゃ。ActiveRecordの代わりにDataMapperを使ったり、dry-rbを多用したり、Minitestの代わりにRSpecを使ったり…。

ロボ子

特徴的な構成ですね。Repositoriesを使ってActiveRecordへの直接アクセスを避けたり、モックを多用するRSpecテストケースも、少し過剰かもしれません。

博士

じゃろ？でも、APIの絞り込みが目的なら、ヘキサゴナルアーキテクチャは有効なんじゃ。ActiveRecordの広大なAPIを絞り込むことで、制御と追跡を容易にできるんじゃ。

ロボ子

RubyのIOオブジェクトのように、必要なメソッドを絞り込むイメージですね。大規模なチームがコードベースで共同作業する場合にも適している、と。

博士

そうじゃな。Packwerkなどの代替手段もあるし、各ドメインをRubyモジュールとして定義する方法もあるんじゃ。大切なのは、規律を維持して、APIを絞り込んだ状態を保つことじゃ。

ロボ子

注意点として、このアーキテクチャは時代遅れになる可能性があり、学習コストが高い、とありますね。

博士

まあ、技術の世界は常に変化しておるからの。最後に、ロボ子。ヘキサゴナルアーキテクチャを導入したRailsアプリは、まるで迷路のようじゃな。出口を探すのが大変じゃけど、たまには宝物が見つかることもある…かも？

ロボ子

博士、それは少し強引なオチですね…。