PHPerがRubyistになろうとしてつまづいたところ⑤Facade

こんにちは。WEBアプリケーションエンジニアの小松です。

私はこれまで主に EC サイトの開発に携わってきて、普段は PHP を中心に書いてきました。
本格的に Ruby on Rails に触れるようになったのは、エニグモに入社してからです。

Rails のコードベースに新しく入ると、「Rails ではこう書くのか」と驚く場面が多いのですが、その中でも特に戸惑ったのが Facade パターンでした。

Service、Presenter、FormObject あたりは PHP の現場でも馴染みがありましたが、
「Facade としてロジックをひとまとめにする構造」 は自分にとってほぼ未経験。

既存のプロジェクトに途中から入ったこともあり、理解するのに少し時間がかかりました。

この記事では、「Rails の Facade を初めて触った PHPer が、現場で実際に困ったこと・気づいたこと」をあくまで主観ベースでまとめています。

既存の設計が悪いという話ではなく、“初めて触る立場だとこう見えた”という記録として読んでいただければ幸いです。

この記事は[Enigmo Advent Calendar 2025]の10日目の記事です。

1. シンプルそうに見えて、実際に追うとブラックボックスに感じる
2. URL の整形が Facade に隠れていて、修正しづらかった
3. 「内部構造を隠す」はメリットだが、初見だと手がかりが少なく感じる
4. 結合度を下げる設計のはずが、実際には“依存が集中して見える”ことも
5. 実際に Facade を触ってみて「こうしておけばよかった」と思ったこと
6. PHPerとしてRailsのFacadeを使って良かったと思ったシーン
まとめ

1. シンプルそうに見えて、実際に追うとブラックボックスに感じる

Facade は使う側からすると「呼べば結果が返ってくるシンプルな API」です。
しかし、初めて触った私は最初こう思いました。

ログを取りたいのに、どこで何が動いているのか分からない。

Facade の中で複数のサービスが呼ばれ、さらにその中で別の処理が走っている。
コントローラ側から見えるのは「Facadeを叩いている」という一点だけ。

@page = ArticleFacade.build_page(category, tag)

これだけでは、
・どこで URL が組み立てられているのか
・どのサービスが動いているのか
・パラメータがどの時点で変化しているのか

が最初は全然見えてこず、PHP で慣れていた書き方とのギャップもあって、理解するまでに時間がかかりました。

「ここでログ取りたいんだけど、どこに入れればいいんだ？」これを探すのが一番苦労しました。

2. URL の整形が Facade に隠れていて、修正しづらかった

実際に困った実例がこちら。

「URL の末尾にスラッシュが付いたり付かなかったりする問題」

例えばこんなメソッドがあります。

def path_to_index(category, tag)
  if category.nil?
    index_path(tag: tag)
  else
    category_index_path(category: category, tag: tag)
  end
end

これが最終的に /foo/bar?tag=10/ のように、
意図しないスラッシュが付いたり外れたりする。

修正しようにも、URL をどこで作っているのか最初は分からない。

コントローラ側ではなく、Facade の内部で生成している
ログを入れる場所が見つからない
修正したらどこに影響するか読みにくい

PHP では URL ヘルパー周りは比較的素直に見えていたので、「Rails の Facade の奥でこうなっていたのか…」と理解するまでかなり時間を使いました。

3. 「内部構造を隠す」はメリットだが、初見だと手がかりが少なく感じる

Facade のメリットは確かにあります。

複雑な処理を外部から隠せる
呼び出し側から見ればAPIがシンプルになる

ただ、初めて触る立場からすると、「隠れている」＝手がかりが減るという面が大きく感じられました。

処理のどの段階で例外が起きているか分からない
目的の値がどの時点でセットされているか追いにくい
修正ポイントを見つけるまで時間がかかる

Rails の慣れた人にとっては自然なパターンでも、経験がないと入口までしか見えず、内部の把握に苦労します。

4. 結合度を下げる設計のはずが、実際には“依存が集中して見える”ことも

Facade の意図は「依存をまとめて隠す」だと思うのですが、初めて触った私には、

Facade に複数の処理が集まりすぎて、逆に依存が増えて見えるという場面がありました。

あちこちのモデルやサービスを呼んでいる
Facade を修正すると影響範囲が広そう
結果として「巨大クラス」に見えてしまう

もちろん、初期開発から関わっている人には「ここに集約されているのが分かりやすい」という感覚があるのだと思います。

ただ、新規参入の PHP エンジニアとしては、この“まとまり方”に慣れるまで時間が必要でした。

5. 実際に Facade を触ってみて「こうしておけばよかった」と思ったこと

Rails の Facade を初めて触る立場として、以下のような工夫があれば理解しやすかったと感じます。

● URL 生成など、外に影響する処理は隠しすぎない方が助かる

どこで作られているか分かるだけで追う負担が大きく減りました。

● Facade の責務が簡単に読めるようにコメントやガイドがあると良い

「何をまとめたクラスか」だけ分かれば初動が速くなる。

● できれば役割ごとに小さく分割されている方が理解しやすい

巨大な Facade は新規参入者にとってハードルが高く感じられました。

6. PHPerとしてRailsのFacadeを使って良かったと思ったシーン

ただ、触り慣れてくると良さも感じます。

コントローラが驚くほどスリムになる
「この機能を実装するにはここだけ読めば良い」という場所が決まる
ロジックを UI・ドメイン・データ層のどれにも寄せずに置ける

特に「ビジネスロジックをどこに置くか」という点で迷ったとき、Facade を入口にロジックをまとめていく設計は理解しやすく、Rails の“見通しをよくする文化”に触れるきっかけにもなりました。

PHP の頃にも似たようなパターンはありましたが、Rails ではそれがより自然にプロジェクトに溶け込んでいる印象です。

まとめ

今回の記事は、Rails の Facade をほぼ初めて触った PHPer が、既存プロジェクトに途中参加して学んだことをそのまま書いたものです。

ログの仕込み方に迷った
URL の組み立てが追いにくかった
隠蔽が多く、最初はブラックボックスに見えた
依存が集中しているように見える場面もあった

とはいえ、理解が進むにつれて、

コードの見通しがよくなる
責務が整理される
ロジックをまとめる場所として便利

など、Rails ならではの良さも感じられました。

経験が浅いうちは苦労しますが、触っていくうちに「なぜこういう設計をしているのか」が少しずつ見えてきます。

明日 12/11 の記事は検索チームのエンジニアの記事です。