株式会社リゾーム システム企画・開発部 第3グループの鳥井です。
読書会の第5回目のレポートです。
前回のレポートは、こちらです。
5回目レポート
今回は、第5章「アプリケーション機能を組み立てる」で参加者は5名でした。
それぞれの感想・意見交換
三層+ドメインモデル
- 三層とRailsにおける処理の対応関係は以下のように捉えることができそう
- プレゼンテーション層
- ルーティングとコントローラーの不正パラメーターのフィルタリング
- アプリケーション層
- コントローラーの各アクションでの処理やサービスクラス、モデル
- データソース層
- モデル
- プレゼンテーション層
- 複数のモデルにまたがるような複雑なビジネスロジックをサービスクラスにするものだと考えていたが、そうでないことに気付かされた
シナリオクラス
- サービスクラスを組み合わせたシナリオクラスを作ることで、業務の視点で必要とする機能単位を表現できる
- 小さいサービスクラスをサービスクラスでまとめるという発想はなかった
メソッド
- メソッドの処理が複雑になってきたら小さいメソッドに分けることでシンプルにできる
- 小さく分ける基本の形として登録系と参照系で分けるのはわかりやすい
DB操作と業務ロジック
- CRUD指向のフレームワークではDB操作と業務ロジックが混在しがちになる
- 業務の関心事をDB操作に置き換えてコードを書くことによってプログラムから業務の意図が見えづらくなる
- Railsでは分離しづらそう
- メソッドにして対応する？
防御的プログラミングと契約による設計
- 防御的プログラミングではメソッドを呼び出す側が何をしてくるかわからないという前提であらゆる防御的なロジックを書くため、コードが複雑になる。それによりテストも増える。
- 契約による設計ではメソッドを呼び出す側と呼び出される側で約束事を決めることでコードをシンプルに保てる
- 実際に業務の中で契約による設計を意識し、メソッドを呼び出す側に責任をもたせて、渡す引数の型情報などをyardで書くようにしている
まとめ
本書で説明されている三層+ドメインモデルの構造や用語をRailsに置き換えて読み進める際、用語の定義の違いに混乱することがありましたが、両者を比較することで新しい設計パターンを知ることができたと思います。それぞれのメリットとデメリットを踏まえて最適な設計を模索し、業務に取り入れていければと思います。
また、読書会全体を通して経験のあるエンジニアの会話の内容を聞いているだけでも勉強になると感じます。
特にリモートワークでは個人で作業する時間が多くなりがちです。その中で、読書会はエンジニア同士の会話の中から新しい知見を得られる貴重な場となるため、今後も継続して参加していきたいと思います。
