Shoken Startup Blog

KitchHike Founder/CTO

Trailblazer勉強会に参加してきた #trbtky

Trailblazer::Tokyo #1@クラスメソッドに参加してきました。

connpass.com

発表者

  • @kbaba1001
  • @yuukigoodman

Trailblazerとは

A new architecture for Rails.
apotonick先生の考えた最強のRails.

github

github.com

Trailblazer は Rails に新しいアーキテクチャを提供する gem です。 Rails のメンテナンスしづらさや複雑さはビジネスロジックが MVC に混ざっていることにあります。 Trailblazer ではビジネスロジックを MVC から分離することで Rails のメンテナンス性を向上します。

引用 http://connpass.com/event/20137/

READMEが充実しているので、読むだけでも概要はつかめる。ソースコードでの例も多く、コード例を眺めるだけでもなんとなくならわかる。サンプルアプリもあるので、そのソースを使い方はわかる。

発表者の@kbaba1001さんいわく、Trailblazerは、開発者であるapotonick先生が業務で多くのレガシーコードと向き合う中で見つけた解決策の集大成なのだとか。思想が先にあって、それをRailsに落とし込んだものではない。なので、机上の理想論ではなく、実現性の高い現実解となっているのがステキなところ。自分で苦労しながら導きだした一つの現実解を汎用的に再構築し、Githubで公開してメンテナンスしている開発者のapotonick先生はエラい。

apotonick先生は充実したREADMEだけではなく、Trailblazerに関する本も執筆している。

leanpub.com

プロジェクトに導入する際には、この教科書が唯一指針となる。英語で200ページ以上。学習コストとしては低くはないが、指針があるのでメンバー間のブレが出にくいのは大きい。

以下は勉強会中にとったメモです。

Trailblazer の紹介 (@kbaba1001)

Trailblazerが解決する課題

Railsは規模が大きくなるとメンテナンスしづらい

  • ビジネスロジックのあるController、再利用しづらい
  • partialがたくさんあって、変更による影響が追いにくい
  • default_scopeを付けている時、外す時が大変。リレーション側からのアクセスだとunscopeで外せない
  • accepts_nested_attributes_for。いっしょに関連するモデルを作る機能。モデルとモデルが密接な結合になってしまってメンテナンスがしづらくなる。
  • validationをifオプションで切り替えをすると、メンテナンスしづらくなる。例: Amazonの買い物かごのウィザード。テストで再現が難しい。後でAPIで登録する場合は書き直しになる。
  • Rails Engineを使うgemの拡張。DeviceやRails adminでcontrollerを上書きすると後々のメンテナンスが大変。gemごとに上書き方法が違う。
  • fat model, fat controller
  • 遅いテスト

課題に対するフォース

apotonick先生の考えた最強のRails

Trailblazerとは、A new architecture for Rails.
cells, reformなどapotonick先生が開発したgemを多く取り入れている。

具体的には、app/conceptsというディレクトリを作って、その配下に機能ごとにディレクトリ作成する。

  • ビジネスロジックをMVCから分離してconcepts以下にまとめる
  • MVCを疎結合にしてメンテナンス性の向上
  • Model: associationとscopeだけを書く
  • View: concepts毎にViewModelとして分割
  • Controller: オペレーションに対するHTTPエンドポイントのみを提供。Strong Params、Modelをfindしない。

ビジネスロジック

  • CRUD
  • validation/callback
  • Viewのためのロジック
  • Worker

一言でいうとMVC + Operation + Cell

サンプルアプリ
https://github.com/apotonick/gemgem-trbrb

Operationとは

Modelのラップ

ビジネスロジックを書く、CRUD, validation, callback

Controllerからのrunメソッドで、processメソッドが呼ばれる

Cellとは

ViewModel

メソッドとassetsのあるpartial

concepts/{機能ディレクトリ}/以下のcell.rbに定義されているメソッドを呼べる

テスト

Operation, cellのテストを行うことで、featureテストやrequestテストを減らすことができる。

partialだけのテストは書かないが、cellのテストができる。細かい単位でテストができるメリット。

Trailblazerと自動テスト (@yuukigoodman)

  • なぜTrailblazerか
  • 電子書籍について
  • とりあえずやってみた前後のdiff
  • Tarilblazerの情報源とか

情報源

DDDの知識は必須では無いが、fat modelに苦しんだ経験から良い設計を勉強する過程で勉強することになるだろう。

以下が揃ったプロジェクトなら、導入できるかも。

  • メンバーがfat modelに苦しんだ経験、良い設計への興味
  • テスト重視
  • Version 2.0が計画されていること。長期メンテナンスが予定されていること。

apotonic先生の教科書が唯一指針になっているので、学習コストは多いが指針はぶれなさそう。

Trailblazer を業務で使ってみた話 (@kbaba1001)

iOSのバックエンドAPI開発でTrailblazer(reform)を使ってみた

解決したかったこと

  • APIリクエストの妥当性検証
  • モデルとリクエストパラメータの疎結合化

Grapeは未使用

コントローラ、モデルでをやりたくなかったので、フォームオブジェクトを作った

reform

modelを継承して、propertyとvalidationを書ける。modelとformを分離するためのgem。

ActiveRecordは入れ子のパラメーターが扱いにくい。reformで解決する。

  • バリデーション、massassignment対策
  • 入れ子パラメータが使える
  • 項目が任意に増えるフォームで、配列を受け取ることができる
  • 複数モデルにパラメータを分配できる
  • モデルに定義されていないカラムをpropertyに書いてvirtual: trueで書ける
  • モデルに書かれていたvalidationのifを無くすことができる。コンテキストによる混乱が無くなる。

コントローラのテストはしにくい。model.saveをコントローラでやっているが、saveメソッドを上書きすることで対応。request specに書かれていたものがservice specに移る。

service層でmodel層をラップしているイメージ

  • ビジネスロジックをサービス層に封じ込めた
  • サービス層でテストするので速い。serviceでcreateして、saveするテストを書けば良い。

Trailblazerが提供するもの => Operation層

  • RailsにもMVC以外の層を作ってもよい
  • Trailblazerのgemは小さい
  • 小さなgemを組み合わせる導入の柔軟さ
  • テストしやすさを重視

apotonick先生が仕事の過程で見つけた現実解。思想が先にあってそれをRailsに合わせたわけでは無いので、現実的である。

勉強会で仕入れた新しい情報メモ