なるセミ「実践クリーンアーキテクチャ」に参加しました
Youtubeのライブ配信で行われたイベントに自宅から参加。設計理論にとどまらない話を聞ければと期待していたが、予想以上に濃い2時間だった。
背景
nrsさんの開発チームでは、APIの定義やDBの選定すらそもそもできていない段階で先にステークホルダーに画面を見せなければならなくなってしまったらしい。ステークホルダーにとっては画面こそが最重要である。よくある話すぎてつらい。
ユーザの求める体験に即した画面を作るには、プロトタイプを作って検証し、壊して作り直すサイクルを素早く回したい。しかし、それにはスケジュール上の余裕が必要だし、そもそもAPIやDB次第で画面が実現不可能になってしまう可能性もある。クリティカルパスを避けながら、できるところを先行して開発するために、解決策の一つとして取り入れたのがクリーンアーキテクチャだった。
クリーンアーキテクチャの最大の特徴は、ビジネスロジックをEntityに詰めることで点在を防ぐこと・そして依存性逆転を用いて詳細を抽象に依存させ、詳細の決定を先送りさせることにある。
例えば、Interfaceを作ってStubUserAddInteractorクラスを実装すれば、仮の実装のままユーザ追加のテストを行うことができる。Interfaceを挟むことでフロントエンドがAPIの詳細な実装に依存しなくなり、開発を進めやすくなる。また、MVCフレームワークではDIを使うことができるので、InjectしたInterfaceの実装クラスを設定ファイルで変えることもできる。
クリーンアーキテクチャで開発するうえの問題点と解決策
とはいえ、一つのアーキテクチャのやり方を丸ごと取り入れられるケースは滅多にない。今回の場合、以下の3つの問題が発生したという。
- PresenterとMVCフレームワークが合わない。本来のクリーンアーキテクチャの場合InteractorがPresenterに出力を返すが、MVCフレームワークではControllerがServiceからレスポンスを受け取らなければならない。
- ユースケースごとにUseCaseInteractorを作ってControllerにInjectしないといけない。そのため、ユースケースが多いとInject地獄になる。
- 作らないといけないクラス・Interfaceが多くなってしまい、作業が辛い。
nrsさんのチームでは、これらを以下のように解決した。
- Presenterは思い切って捨てた。Controllerには素直にデータの値を返し、それをフロントに戻す形式を採った。クリーンアーキテクチャからは外れてしまうが、MVCフレームワークであればそこまで不自然な流れではない。
- Inject地獄の対応としてMessage Busを作った。Message Busの中では、どのInputDataが来たらどのInteractorを使うか登録してあり、呼び出し側ではBusの中でどのInteractorを使うかは知らない。つまり、ControllerにInjectを書かなくてよくなり、ユースケースが追加されたらMessageBusを直せば良い。
- クラス多い問題は、スカフォールディングツールを作ってコードを自動生成させるようにした。
感想
アーキテクチャの理論を勉強できる機会は多いが、実践に落とし込んだときの問題点まで聞けたのは貴重な機会だった。MVCフレームワークと完全には合わないという話は、自分も古典的MVCとMVCフレームワークが完全に合っていないことで悩んでしまった経験があるためとても参考になった。単にそのまま適用できないという所で止まらずに、どう乗り越えるかを考えることこそがアーキテクトの真髄なのだろう。 また、この記事では省いたが、前半部分のクリーンアーキテクチャの解説も非常にわかりやすく、後半の実践例の話がうまく腹落ちするようになっていた。アーカイブはまだ残っているのでぜひ聴いてほしい。
