「現場で役立つシステム設計の原則」読書会 vol.7

第7回の感想です。前回の感想はこちら。

patorash.hatenablog.com

会社のブログのレポートはこちら。

なお、この回の会社のブログのレポートの担当が私だったので、書きたいことはそちらにほぼ書いちゃってる…。

7章画面とドメインオブジェクトの設計を連動させる

画面にロジックを埋め込むと複雑化してくるのはすごくわかる…。
表示のためのロジックと業務ロジックを分ける意味では、ビューヘルパーを使ったり、デコレーターを噛ましておくといいとは思う。Railsの場合はビューヘルパーはグローバルメソッドのようになってしまうので、あまり好みではないけれど、契約による設計を重視した形にすれば、あまり散らからないかもしれない。定義場所は整理できるし。
今作っているサービスだと、何でも入力画面になっている。関心事を分離することができれば、入力ステップ数は増えるものの、ドメインオブジェクトで整理できそうに感じた。なんでも入力画面だと、全部入力するのに時間がかかって疲れて離脱してしまうので、本当によろしくない。後で入力すればいいものまで、必須にする必要はない。
最近感じているのだが、バックエンドのドメインオブジェクトとフロントエンドのドメインオブジェクトが流用できないのが歯がゆい。Rubyでドメインオブジェクトを作り、さらにJSでドメインオブジェクトを作らなければならない。ほとんど似たようなものを、だ。そしてそれぞれをテストしなければならないのが面倒。共通で使えたらいいのにと感じる。
pixtaが次のシステム刷新でRailsをやめてTypeScriptのフレームワークを使うという話をしていた*1と記憶しているのだが、それはバックエンドでもフロントエンドでも同じドメインオブジェクトを使うためなのではないか？JSでは表現力がイマイチだが、TypeScriptだと型も列挙型も使えるので表現力もある。と読みながら思った。
検索項目単位でドメインオブジェクトを作っていくと、扱いがやりやすくなりそう。
タスクベースのユーザーインターフェース、確かに最近多い。入力するものが限られるので、入力する側もサクッと変更できてよい。内部の設計はタスクベースに分けておくべき、とあったので、そうしておきたい。
どこに画面用ロジックを集めるか問題。論理的なビューに関してはドメインオブジェクトでいい、というのはわかる。しかし結局苦しんでいるところは物理的なビューだったりする。物理的なビューに関してはデコレーターに閉じ込めるようにして、論理的なビューはドメインオブジェクトに寄せるようにすれば、納得感はあるかなと思う。
画面とソフトウェアを関係づける。わざわざBookSummaryクラスを作ってしまうのか。ぱっと見、データクラスじゃない？という感じがあるが…。まぁメソッドを定義してないだけか。これもまた、一覧と詳細では関心事が違うよということか。ついついRailsで考えがちなので、モデルで取ったデータをわざわざサマリ用のクラスに詰め替えるんかい、と思ってしまったが、普通に考えたら、データ取得用のクラスでgetSummariesを定義して、そのサマリ用クラスのインスタンスの配列を返せばいいわけだから、Railsじゃなければ、そっちのほうがスッキリするかなと思えた。
画面もドメインオブジェクトで管理したい、となってくると、MVVMを使うようになっていくことになるのは必然。そりゃあReactやVueが流行るのもよくわかる…んだが、よくわかってない人がやってるのを見ると、画面と値が連動していて便利、止まりになっている気がする。
プレスリリース、リリースノート、利用者ガイドの内容がドメインオブジェクトに反映されているのが良いソフトウェアという話。言われてみれば、たしかにそうだなと思う。しかしこれら全ての整合性をとり続けるのは相当難しい。うちの体制だと、メンバーが少ないのでそちらのメンテに手が回りにくい。やはり、せめて1製品につき最低でも3人体制くらいにはしたいものだ。

雑感

物理ビューと論理ビューの分離どうするかというところを課題として考えているのだけれど、Decoratorに論理ビューを作るメソッドを定義し、ViewHelperに物理ビューを作るメソッドを定義していくように分けたら良いかなと思うようになった。という話を会社のブログで書いた。最近はこれを意識してRailsのコーディングしているのだが、どうにも気持ち悪いことが起こる。

気づいたらDecoratorでViewHelperのメソッドを呼んでしまっていたりする。link_toとか。リスト出力でリンクを出したいときなんだけれど、このときに渡したい引数は文字列の配列なので、リンクのHTML文字列を含んだ配列にしておきたいのだが、それを呼ぼうと思うと加工が必要になる。そこをどこでやるか？という話になるんだが、なんだかんだでDecoratorがしっくりきてしまう。

Decoratorはそもそも装飾するのが担当だから、それでいいんじゃないか？とも思うのだが、論理ビューを担当させるだけにしたほうがいいのでは？という結論になったにも関わらず、現実だと結局物理ビューも担当しちゃうようになるから、悩んでいる。

モデルに論理ビューのロジックを移動させて、Decoratorは物理ビューを担当させるようにしたほうが、スッキリするかなぁと思い始めている。Railsのモデルはドメインオブジェクトでもあるので、そのほうがスッキリするかなぁ。

この辺りで悩んでいるのでご意見求めたい。