複雑なロジックをどこに実装すべきか、そのために新しいレイヤーを導入すべきか。導入するならどこまでの責務を持たせるべきか。Railsコミュニティはこうした問いを長らく議論してきました。本発表は、これらの問いを一度手放すことを提案します。実装先に迷うとき、多くの場合、起きているのはレイヤーの不足ではなくモデリングの不足だからです。
Railsのモデルはテーブルと対となる形で定義され、比較的単純なアプリケーションであればうまく機能します。しかし、機能要求が複雑になると、注文の確定や在庫の補充、ポイントの付与といった「操作」に固有のルールが現れます。Railsでは、操作のルールはその主体や対象となるモデルに実装されやすく、独立した概念として見落とされる傾向があります。その結果、これらのモデルが静かに肥大化し、保守性が低下していきます。
本発表では、モデルとそのCRUD操作を中心としたRailsの設計が、高い生産性と引き換えにドメインにおける重要な操作を見落としやすい構造を持つことを解き明かします。そのうえで、ドメインのルールを、それを担うモデルごとに整理し、どの既存のモデルにも帰属しないルールから新しいモデルが生まれるまでの過程を設計判断とともに示します。
本発表のあと、みなさんは実装先やレイヤーを議論する前に問うべきことを手にしているはずです。「このルールを担う概念は何か」という問いです。
2015年にピクスタ株式会社に新卒入社し、開発基盤の整備や開発プロセス改善に従事。2020年に執行役員CTOに就任。2023年より株式会社EARTHBRAINでデータプラットフォーム開発を主導。その後、英国ロンドンへ拠点を移し、現在はWASO LTD.のテックリード兼フルスタックエンジニアとしてプロダクト開発に携わっている。著作に『パーフェクトRuby on Rails【増補改訂版】』（共著、技術評論社）がある。