SQLアンチパターン読書会 「マジックビーンズ(魔法の豆)」に参加しました

2014/11/25(火) SQLアンチパターン読書会 「マジックビーンズ(魔法の豆)」に参加してきました。

Doorkeeper
http://sqlap.doorkeeper.jp/events/17729

以下の書籍をターゲットとした読書会なのです。

SQLアンチパターン (2013/01/26) Bill Karwin 商品詳細を見る

場所は前回同様、秋葉原のクラスメソッド株式会社さんでした。
参加者は9人かな。初参加は2人でした。

ちなみに今回はアクティブレコードがテーマの１つでもあったりするのですが、
「そういや以前、Railsの勉強会でアクティブレコードの章を担当した時にスライド作って発表したっけ・・・」
と思ってslideshare見てみたら、スライドのviewが37000を超えていてフイたｗ

HerokuではじめるRailsプログラミング入門 6-3節「複数モデルの連携」 by @makopi23

キャッチーなキーワードやタイトルに釣られてやって来る人が多いのかな・・・。
正直、スマンカッタ・・・

---

■ 発表
今回は @a_suenami さんが発表担当でした。

マジックビーンズ from Akira Suenami

DDDネタ、RailsのARの弊害などに言及しつつ深く考察されており、よく纏まっています。
DDDネタをよく発信されている増田さんからもコメントが。

ドメインモデルとActive Record に関する実践的で良い考察。参考になるなあ | マジックビーンズ by @a_suenami http://t.co/ZzXuLTfGMS @SlideShareさんから

— 増田 亨． (@masuda220) 2014, 11月 27

---

■ ディスカッション
今回もディスカッションしたいネタをみんなで付箋に書き出しました。


以下、個人メモ。
---

■ 24.2.1 アクティブレコードはモデルをデータベーススキーマに強く依存させてしまう

• Railsでコードを自動生成するとフォームがモデルに乗ってくるので、ビューとDBが密結合になる。。。
• Railsの4から、モデルからフォームを除くことができるようになったらしい。

■ ActiveRecordとDataMapper

• 両者ともMartin Fowlerの通称PofEAA本に登場するパターン。
• ActiveRecord
  • アプリケーション側のモデル構造とDB側のテーブル構造を1:1対応させる」という割り切った特長を持っている。
• DataMapper
  • アプリケーション側のモデル構造とDB側のテーブル構造をn:n対応とし、それらをマッピングさせる。
• ググッたところ、以下のサイトが参考になりそう。
  • データベースことはじめ「パーシステンス層アーキテクチャパターンの選択」
  • 徹底比較!!Ruby on Rails vs Javaフレームワーク「第１回：O/Rマッピング」
• ActiveRecordとDataMapperの両方を使ってみて、どちらにするか自分で決めるのが良い。

■ JOINはActiveRecordとして許されるか

• JOINも隠蔽したほうが良い。
• Railsの場合は、scopeというDSLの層を入れることで隠蔽に成功している。
• リポジトリパターンを使って避ける。

■ SQL vs ActiveRecord

• DBアクセスをSQLを手で書く方が良いか、AcriveRecordに任せる方が良いかは、「生産性」と「平準化」が判断軸になる。
• 生産性
  • 生産性なら、DBアクセスのSQLとコードを手で書くより、ActiveRecordを使ったほうが断然高い。
• 平準化
  • 3年後に修正する場合にもActiveRecrodの方が早いかというと、保守性の観点からそんなことはない。。。
• 「いつ」を照準にするかでどちらが良いか、コンテキストが違ってくる。
• まず市場に早く製品を出して勝つためには、生産性を高めて早く製品を作ることが大前提にある。
• いくら綺麗な設計だったとしても、リリースまでに時間がかかって勝負の土俵にも上がれないようでは負けである。
• ActiveRecordを使う場合、「そのシステムを3年くらい使ったら負け。すぐにポシャったら成功」

■ ドメイン層からインフラストラクチャ層を呼び出すのが自然？

• 以前はそうだったが、最近はAlistair Cockburn の「ヘキサゴンアーキテクチャ」が多くなっている。
  • ドメインとDBの間にパーシステンス層がいて、ドメインはパーシステンス層のことを知らないほうが良いとされる。
  • DBアクセスは、引数にPOJOを渡して「あとはお任せします」的なアクセスとなる。(モデルとDBを疎にする）
• ヘキサゴンアーキテクチャの参考文献
  • InfoQ「ヘキサゴナルアーキテクチャを探る」
  • Qiita「実践テスト駆動開発(GOOS)読んだ」 by 平鍋健児氏

■ 24.2.4 マジックビーンズのユニットテストは困難

• テストについては、半年前くらいに話題になった「TDD is dead」が深く関わっている。（翻訳版 by やっとむ氏）
  • 「TDD is dead」は、「テストを考えることで良い設計になる」という本来のTDDの思想から離れてしまっている。
  • 手段が目的になっている。そうじゃなく、バランスを持った議論が必要。
• DBのモックを作るのは負けパターン。
  • 最近はマシンスペックが上がっているので、DBを使ったテストをするのが良い。
  • ただ、それは2014年だから言える。原著が書かれた当時は、この手のネタが盛んだった。

■ 寿命が長い方を綺麗に

• ビューよりも、データやURLのほうが寿命が長いので、きちんと設計をしないといけない。
• その順序を間違えて、コードとモックの綺麗さばかりに引っ張られるのはダメ。
• 基本的な考え方は、「寿命が長い方に寄せる」。

■ 「犠牲的アーキテクチャ」関連の考え方

• Martin Fowler氏のブログで「犠牲的アーキテクチャ」という考えが紹介された。
  • システムは数年後に破棄してリプレースしないといけない、という考え方を受け入れ、それが容易になるよう事前に考慮しておく、という考え方らしい。
  • 参考： InfoQ 「Martin Fowler氏の語る“犠牲的アーキテクチャ"」
• 伊勢神宮も、20年に一度、建物を造り替える「式年遷宮」がある。
  • 大きなものはいつか死んで総崩れになるので、大きくなる前に分割して、寿命を分断する。
• システムも同じで、ビジネスが軌道に乗り始めたからといって、早さ優先で開発した創業当時のコードをいつまでもコピペしていると死ぬ。
  • 最後まで生き残るのは「データ」と「データのインタフェース」。
  • コードは、その時その時のトレンドに合わせて、得意なものを使うべき。適材適所なアーキテクチャを採用する。
  • ただし、DBやWebのインタフェースとなるデータやURIは「約束事」なので、最後まで生き残らせないといけない。
  • ドメイン、データ、インタフェース。この３つは生き残らせないといけない。
  • パターンと実装を切り離せ。

■ 実装とパターン

• 20年前は、「パターン ⇒ 実装」だった。パターンが先にあって、そこから実装例が出てきた。
• 今は「実装 ⇒ パターン」の時代。最新のコードから、野生のパターンが出てくる。
• そういう意味で、本が設計を引っ張る時代は終わった。
• ActiveRecordは、「実装」が「パターン」を超えている例。

---

★感想：
奥野さんの25章を除けば実質最終章ということもあって、なかなか高度な内容を扱う章でした。
私もRailsのアクティブレコードは前述したRails勉強会で触った程度なんですが、初めて触れた時は、かなり異質に感じました。
そんなの特殊な状況でしか使えないじゃん、自分でDBアクセスのコード書けばいいじゃん、みたいな。
今回この章でいろいろ学んで、いろんな考え方があるんだなぁ、と再認識しました。

あと、 @t_wada さんの「本が設計を引っ張る時代は終わった」という言葉は重いです。。。
いつまでも本でINPUTばかりしてるようじゃダメですね～

あと、誤植っぽいところを @t_wada さんにチラッと報告したが、ここにもメモ書きしておく。
P.268のenterActionメソッドで、$accountTalbe変数が未使用。
P.268のdisplayActionメソッドで、$productTable変数が未使用。メソッド最終行の$bug変数も未定義。

残すは忘年会と、奥野さんの25章のみ。終わりが見えてきましたね。
参加者の皆様、ありがとーございました。

---

■おまけ：過去の「SQLアンチパターン読書会」ブログ

1章：SQLアンチパターン読書会 「ジェイウォーク」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-65.html

2章：SQLアンチパターン読書会 「ナイーブツリー」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-70.html

3章：SQLアンチパターン読書会 「IDリクワイアド」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-73.html

3章：SQLアンチパターン読書会 「続・IDリクワイアド」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-77.html

4章；SQLアンチパターン読書会 「キーレスエントリー」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-84.html

5章：SQLアンチパターン読書会 「EAV(エンティティ・アトリビュート・バリュー)」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-90.html

6章：SQLアンチパターン読書会 「ポリモーフィック関連」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-94.html

7章：SQLアンチパターン読書会 「マルチカラムアトリビュート」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-97.html

8章：SQLアンチパターン読書会 「メタデータトリブル」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-105.html

9章：SQLアンチパターン読書会 「ラウンディングエラー」 に参加しました
　http://makopi23.blog.fc2.com/blog-entry-109.html

10章：SQLアンチパターン読書会 「サーティーワンフレーバー」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-115.html

11章：SQLアンチパターン読書会 「ファントムファイル」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-118.html

12章：SQLアンチパターン読書会 「インデックスショットガン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-121.html

13章：SQLアンチパターン読書会 「フィア・オブ・ジ・アンノウン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-128.html

14章：SQLアンチパターン読書会 「アンビギュアスグループ」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-130.html

15章：SQLアンチパターン読書会 「ランダムセレクション」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-133.html

16章：SQLアンチパターン読書会 「プアマンズ・サーチエンジン」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-134.html

17章：SQLアンチパターン読書会 「スパゲッティクエリ」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-136.html

18章：SQLアンチパターン読書会 「インプリシットカラム」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-138.html

19章：SQLアンチパターン読書会 「リーダブルパスワード」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-140.html

20章：SQLアンチパターン読書会 「SQLインジェクション」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-144.html

21章：SQLアンチパターン読書会 「シュードキー：ニートフリーク(疑似キー潔癖症)」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-147.html

22章：SQLアンチパターン読書会 「シー・ノー・エビル(臭いものに蓋)」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-151.html

23章：SQLアンチパターン読書会 「ディプロマティック・イミュニティ(外交特権)」に参加しました
　http://makopi23.blog.fc2.com/blog-entry-152.html