patorashのブログ

方向性はまだない

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

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

patorash.hatenablog.com

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

tech.rhizome-e.com

5章 アプリケーション機能を組み立てる

  • アプリケーション層がサービスクラスとモデルになるのかな?(Rails脳)
  • 複数のモデルにまたがるような複雑なビジネスロジックをサービスクラスにするもんだと考えていたのが、そうでないことに気付かされた。つまり、アクションでやっていることは、殆どがサービスクラスにしたほうがよいことだ。
  • サービスクラスでドメインモデルを組み合わせて処理するけれど、複雑になりやすい。原因の1つに、プレゼンテーション章の関心事に振り回されるって書いてあったが、これはアクションでやっていることがまさにそうであるので納得。
  • サービスクラスが複雑になるということは、ドメインモデルに成長の余地があるということ。サービスクラスに業務ロジックを書くくらいなら、ぎこちない名前でもドメインモデルを作ること。これは意識しないとすぐにロジックをサービスクラスに書いてしまいそう。というか現在が絶賛書いている状態…。リファクタリングしたい!
  • サービスクラスも、小さいサービスクラスを作っても良い。登録系と参照系に分けるのが基本というのはわかりやすい。登録系は副作用があるけれど、参照系は副作用がないので、変更を加えたときにテストしなければならない対象を考える範囲が減るのはいい。
  • 例外を発生させてるのが、どこでも使えるのでいいなと思った。
  • あと、契約による設計の話と防御的プログラミングの話が出てきた。これはプリンシプル オブ プログラミングを読んだ際に感銘を受けたので、チームのコーディングルールとしても、契約による設計を取り入れている。でもやっぱり同時実行の可能性を考えてチェックを入れたりはするんだなと思ったので、その辺りは見直したほうが良いかもしれない。
  • サービスクラスにシナリオクラスという名前をつけるの、イケてる。業務シナリオでプレゼンテーション層から分離できるから、テストしやすくなるのが最高。
  • データベースの都合から分離する、のところ。Railsはかなり分離しづらい。まぁできなくはないけれど、そういう視点を得たエンジニアでないと難しそう。メソッドにしていくくらいしかないだろうか?

雑感

参加者のほとんどが業務でRailsを使っているので、「Railsで考えると、こう」というふうに置き換えて考えてしまいがち(自分含めて)。他のアーキテクチャを見たことがない人は言葉で混乱しているみたいでした。 対照的に、.Netを使っている参加者は、業務で使っているのが3層アーキテクチャと、本に載っているJavaのコードに近いので、よくわかるとのことでした。

この本を読めば読むほど、RailsではないDDDをやりやすいフレームワークのほうが大規模開発には向いてるだろうなぁ~とふつふつと感じてます。まぁRailsはOne Person Frameworkだからなぁ~という話をしたりしました。

world.hey.com

あとは契約による設計についてと防御的プログラミングに関する認識について意見交換したり等…。引数の型が違ったら例外を上げるコードを書いてるという話があったので、それ契約による設計じゃなくて防御的プログラミングのほうやでって言ったり。

契約による設計は契約があるのだから、そもそも引数に異なる型の値を与えるのは、基本的に呼び出した側の責任となるはず。メソッド側で型が違うかどうかを毎度毎度チェックしてたら大変じゃんっていうのが私の意見というか契約による設計に対する認識。その代わり、ドキュメントをしっかり書いて、どの型を与えるべきかを明示しなければならないので、yardをしっかり書くことっていうルールにしてるよって話した。

だいたい、こんな話してたと思う。

  • 「とはいえ1行、型のチェック入れるだけじゃないですか?」
  • 私「だったら引数がある場合に全部のメソッドに対して型チェック入れてくの?って話になるので、面倒じゃない?」
  • 「うーん、たしかに…。しかしRubyだと実際入れられちゃうじゃないですか。そこどうするんですか?」
  • 私「だから、契約なんだから、そんなことをする人は契約違反でしょ?」
  • 「いやまぁ確かにそうなんですけど、実際入れられちゃうじゃないですか」
  • 私「そこをめっちゃ気にするんならRuby使うべきじゃないんじゃない?Javaなら起きないよ」
  • 「うーん、そうですねー…」
  • 私「この本に載っているように、canWithdrawメソッドのような可能かどうかのチェックを入れて、そもそも呼ばれるのを事前に防ぐべきだと思うよ」
  • 「なるほど」
  • 私「同時に呼ばれたりして副作用が起きかねない場合は、本の中のwithdrawメソッドでも例外上げてたりするから、そうするべきかなぁ」

意見交換したり、認識の確認とかできたので有意義な会となりました。