Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Active Recordについてわかったことを説明するよ
Search
bayashi
December 23, 2022
Programming
0
500
Active Recordについてわかったことを説明するよ
一年前くらいに社内勉強会で発表した資料です。
公開しても問題なさそうなんで公開
bayashi
December 23, 2022
Tweet
Share
More Decks by bayashi
See All by bayashi
複雑さを受け入れるか、拒むか? - 事業成長とともに育ったモノリスを前に私が考えたこと #RSGT2026
murabayashi
1
3.3k
エンジニアに事業やプロダクトを理解してもらうためにやってること
murabayashi
0
380
自分がLinc’wellで提供しているプロダクトを理解するためにやったこと
murabayashi
1
500
エンジニアとして関わる要件と仕様(公開用)
murabayashi
0
550
個人事業主型開発からの脱却
murabayashi
14
10k
スクラムフェスを支える配信の仕組み
murabayashi
1
1.2k
締切とはなにか、どういう効果があるのか #scrummikawa
murabayashi
0
1.5k
商用アプリケーション開発基本のキ
murabayashi
0
310
(新米)エンジニアリングマネージャーのしごと #RSGT2023
murabayashi
11
11k
Other Decks in Programming
See All in Programming
AI 開発合宿を通して得た学び
niftycorp
PRO
0
150
Claude Code の Skill で複雑な既存仕様をすっきり整理しよう
yuichirokato
1
410
What Spring Developers Should Know About Jakarta EE
ivargrimstad
0
400
AWS×クラウドネイティブソフトウェア設計 / AWS x Cloud-Native Software Design
nrslib
16
3.3k
Ruby and LLM Ecosystem 2nd
koic
1
980
「接続」—パフォーマンスチューニングの最後の一手 〜点と点を結ぶ、その一瞬のために〜
kentaroutakeda
1
420
条件判定に名前、つけてますか? #phperkaigi #c
77web
1
120
それはエンジニアリングの糧である:AI開発のためにAIのOSSを開発する現場より / It serves as fuel for engineering: insights from the field of developing open-source AI for AI development.
nrslib
0
130
Rで始めるML・LLM活用入門
wakamatsu_takumu
0
190
AI駆動開発の本音 〜Claude Code並列開発で見えたエンジニアの新しい役割〜
hisuzuya
4
520
GoのDB アクセスにおける 「型安全」と「柔軟性」の両立 - Bob という選択肢
tak848
0
210
Claude Codeセッション現状確認 2026福岡 / fukuoka-aicoding-00-beacon
monochromegane
4
440
Featured
See All Featured
Stewardship and Sustainability of Urban and Community Forests
pwiseman
0
150
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
61k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8.9k
BBQ
matthewcrist
89
10k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
290
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
180
How to Think Like a Performance Engineer
csswizardry
28
2.5k
Applied NLP in the Age of Generative AI
inesmontani
PRO
4
2.2k
Building a Scalable Design System with Sketch
lauravandoore
463
34k
The Mindset for Success: Future Career Progression
greggifford
PRO
0
280
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
199
73k
How Fast Is Fast Enough? [PerfNow 2025]
tammyeverts
3
490
Transcript
家政婦は見た! 命を張った好奇心 Active Recordの正体と 犠牲にされた疎結合 命を張った好奇心 Active Recordの正体と 犠牲にされた疎結合
最近 設計の本とかパーフェクト ruby on railsとか読んでActive Recordが何なのかちょっとだ け理解できてきたので語っていきます。
Rails ガイドのActive Recordとは 1 Active Recordについて Active Recordとは、MVCで言うところのM、つまりモデルに相当するものであり、ビジネスデータとビジネスロジックを表すシステムの階層です。Active Recordは、データベースに恒久的に保存される必要のあるビジネスオブジェクトの作成と利用を円滑に行なえるようにします。Active Recordは、ORM
(オブジェクト/リレーショナルマッピング)システムに記述されている「Active Recordパターン」を実装したものであり、このパターンと同じ名前が付けら れています。 1.1 Active Recordパターン パターン名としてのActive RecordはMartin Fowler『Patterns of Enterprise Application Architecture』という書籍に記述されています。Active Record パターンにおいて、オブジェクトとは永続的なデータであり、そのデータに対する振る舞いでもあります。Active Recordパターンは、データアクセスのロ ジックを常にオブジェクトに含めておくことで、そのオブジェクトの利用者にデータベースへの読み書き方法を指示できる、という立場に立っています。 https://railsguides.jp/active_record_basics.html#active-record%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6
PoEAA https://www.amazon.co.jp/dp/B01B5MX2O2/
PoEAAのActive Recordとは データベースのテーブルやビューの列をラップし、データベースアクセスをカプセル化し、ドメインロジックを追加するオブジェクト データと振る舞いの両方を持つオブジェクト。データの多くは永続的であり、データベースに格納される必要がある。 ActiveRecordは、メイン オブジェクトにデータアクセス処理を置くという最も明らかなアプローチを採用している。この方法では、全員がデータベースへの読み書きす るやり方を知っている。 https://bliki-ja.github.io/pofeaa/ActiveRecord/
Active Recordとは 1. データベースのテーブルやビューの列をラップし、 a. 1テーブル、1クラス。クラスの属性は、テーブルの各カラムに対応 2. データベースアクセスをカプセル化し、 a.
ORM 3. ドメインロジックを追加するオブジェクト a. ドメインロジック?なんだそれ
ドメインとは ドメインは「領域」の意味をもった言葉です。ソフト ウェア開発におけるドメインは、「プログラムを適用 する対象となる領域」を指します。重要なのはドメイ ンが何かではなく、ドメインに含まれるものが何か です。 成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本
ドメインとは たとえば会計システムを例にしてみましょう。会計 の世界には金銭や帳票といった概念が登場しま す。これらは会計システムのドメインに含まれま す。物流システムであればどうでしょうか。会計シ ステムとは打って変わって貨物や倉庫、輸送手段 などの概念が存在し、それらがそのまま物流シス テムのドメインに含まれます。
成瀬 允宣. ドメイン駆動設計入門 ボトムアップでわかる!ドメイン駆動設計の基本
モデルとは 「モデルとは、何らかの実体があって、それ を縮小(あるいは拡大)して細かい部分は 省いて自分たちの都合の良いところだけを 抽出して形成した形のことである。」(知り合 いのモデラー談)
モデルとは 同じ人間だけど、「スポーツをする人」と捉 えたときと「転職をする人」と捉えたときで 抽出する情報は変わってくる。 自分たちがシステム化したいドメインに関 して対象をモデル化したものを ドメインモデ ルと呼ぶ。
Active Recordをドメインモデルと呼んでる 人はあんまりいないけど広義にはActive Recordもドメインモデルになると思う。
RailsのActive Recordを継承したmodel - 値のチェック - ユースケースの組み立て RailsにおけるActive Recordがやってくれること
値のチェック →validation ユースケースの組み立て →after_createとか Active Record パターン - DBをラップ - ORM - ドメインロジック
僕がやったことのあるSpring(Javaのフレームワーク) 値のチェック → form object ユースケースの組み立て → service ORM →
repository DBをラップ → なかった気がする ドメインロジック → Entity 確かこんな感じだった気がする...
RailsのActive Record - 値のチェック - ユースケースの組み立て RailsにおけるActive Recordがやってくれること
値のチェック →validation ユースケースの組み立て →after_createとか Active Record パターン - DBをラップ - ORM - ドメインロジック
RailsのActive Record - 値のチェック - ユースケースの組み立て RailsにおけるActive Recordがやってくれること
値のチェック →validation ユースケースの組み立て →after_createとか Active Record パターン - DBをラップ - ORM - ドメインロジック そりゃあFat Modelになりまっせ!
Rails の Active Recordは めっちゃ色んな機能を集約したおかげで便利につかえる あとModelとTableを1:1対応にしたことで何も宣言せずに便利に使える https://speakerdeck.com/yasaichi/what-is-ruby-on-rails-and-how-to-deal-with-it?slide=39
じゃあFat Modelどうするんだ 値object →紹介 ドメインモデルへの切り出し https://qiita.com/MinoDriven/items/3c7db287e2c66f36589a サービスクラスhttps://qiita.com/chrischris0801/items/58a12d17a440b842db02
値オブジェクト パラメータ名 パラメータの型 名前 String 誕生日 date 住所 String 性別
String 人物モデル 各パラメータの制限や便利メソッドはすべ て人物モデルの中にある 制限の例: 誕生日は過去日でないといけな い 便利メソッド: 誕生日から今の年齢を出す
値オブジェクト パラメータ名 パラメータの型 名前 String 誕生日 Birthday 住所 String 性別
String 人物モデル 制限の例: 誕生日は過去日でないといけな い 便利メソッド: 誕生日から今の年齢を出す ↓ Birthdayクラスを作りそこに集約する
こういうのやっていくとRails wayから離れる = 規約のパワーでどうにかできなくなりRailsである必要 ある?状態になる
ちょっとまって本当にまだRails Wayから去る必要ある? tableとmodelが1:1だとして データモデリングちゃんとできてる?
https://www.slideshare.net/HidekatsuIzuno/ss-67532977
人物マージの例 例えば人物マージという機能がある - データ上のAさんとBさんが実際は同一人物(重複登録)だったためマージする機能 人物マージはそもそも人物というモデルの責務なのか? マージされる側の責務?マージする側の責務? controllerは何のメソッド使う?update?delete? merge可能かどうかはどう判定する?
過去自分がやった実装 マージされる側の責務?マージする側の責務? →マージする側(残る側)の責務にしよう...うーん controllerは何のメソッド使う?update?delete? →よくわかんないけどupdateかな... merge可能かどうかはどう判定する? →merge_candidateメソッドの中でチェックしよう...
今の自分がやるなら 人物マージをイベントとして捉えてそれをモデルにする (イベントが発生したらDBにも保存する) マージされる側の責務?マージする側の責務? →人物の責務じゃなくて人物マージの責務
controllerは何のメソッド使う?update?delete? →人物マージのレコードがひとつ増えるからcreate merge可能かどうかはどう判定する? →validateで判定可能 after_createでマージされる側を削除するロジックを組み立てる
参考文献 パーフェクト Ruby on Rails 【増補改訂版】 現場で役立つシステム設計の原則 ドメイン駆動設計入門 https://anchor.fm/textafm