「現場で役立つシステム設計の原則」読書会レポート vol.3

株式会社リゾーム システム企画・開発部 第4グループの平松です。
今回は、読書会の第3回目のレポートになります。
前回のレポートは、こちらになります。

tech.rhizome-e.com

3回目レポート

今回は、第3章「業務ロジックをわかりやすく整理する」で参加者は4名でした。

それぞれの感想・意見交換

データクラスと機能クラス

  • Railsだとコントローラーとモデルの関係
  • コントローラーのアクションに処理をまとめるのは悪手
  • モデルにデータとロジックをまとめておけばコードの重複をなくせるし、テストもできる
    • モデルにデータとロジックを寄せているが、現状、値オブジェクトを使っていないため、半分正解の状態
  • モデルが肥大化したら、値オブジェクトを導入する良いタイミングでは?

ロジックとメソッド

パッケージ化

  • パッケージ化とは?
    • Rubyで言うとmoduleの名前空間で区切ることになるかも
    • コードが冗長になるため、やりすぎには気を付けたい

通化

  • 汎用クラスを使ったとしてもクラス数が多くなると探す手間もかかる
  • 同じような処理が多くできてしまい、使い分けができなくなる
    • RailsだとViewのヘルパーメソッドが汎用的なクラスと似てる

三層アーキテクチャドメインモデル

  • Railsだとデータソース層とドメインモデルが一体化したのがモデルになってる
    • そのおかげで、高速に開発できるが反面、複数のドメインモデルを使ってデータソースに保存する際、どこのモデルにロジックを書くべきか困る。
    • そして、どこかのモデルに書いた場合は、そのモデル同士が密結合になってしまう。
    • Railsの良いところと悪いところが同時に見えて面白い。

まとめ

本のサンプルコードはJavaRubyに置き換えることが難しい部分もありましたが、データクラスと機能クラス、メソッドの使い方など共通して言えることも多くありました。 データとロジック、ロジックとメソッドの関係からオブジェクト指向らしいクラス設計を知ることができたのではないかと思います。

次回は、第4章「ドメインモデルの考え方で設計する」になります。設計は開発の土台となる部分です。ここをしっかりと理解し、弊社のプロジェクトの改善に取り組んでいきたいと思います。