Mix Leap Study 特別編 - レガシーをぶっつぶせ。現場でDDD！コラボカンファレンスに参加しました -- Ruby での開発に活かせるのか？

yahoo-osaka.connpass.com

どうも永田（@kizashi1122）です。このイベントに参加してきました。

参加のモチベーション

「DDD」という言葉は当然知っている。ただあんまりよくわかっていない。エリック・エヴァンスの本も読んでいない。

こんな状態で、「DDD とは何なのか？」を少しでも理解できればなというモチベーションで挑みました。

聞いた発表

ドメイン駆動設計という設計スタイル by @masuda220
DDDのモデリングとは何なのか、そしてどうコードに落とすのか by @little_hand_s
現場でドメイン駆動設計を広げるには何をすれば良いか？ by @tsuyok
抽象的な教えを試行錯誤しながら解釈した DDD の実践レポート by @suzuki_hoge
過去の失敗例から再考するモデル駆動設計 by @j5ik2o

全部メイン会場やないかい。

正直、増田さん（@masuda220）の発表は概念的な内容も多く、しっかり理解できたかどうかは不安でした。ただ後半はコードに落ちる部分の説明もあり、なんとなく「こういうことかな」という理解をしました。

私自身は、今は Ruby で開発しているものの Java の経験者でもあり、特に松岡さん（@little_hand_s）とかとじゅんさん（@j5ik2o）の発表はとても腑に落ちるもので、増田さんの発表の後半の続きのような、よりコード側の説明がありDDD初心者にはとても理解しやすかったです。

ただ、これってDDDと言うかこれって・・・では？と思うところがあり、ちょっとモヤっとしていました（・・・については後述）。

懇親会

登壇者との懇親会の参加させていただきました。ちょうど隣に、登壇者の松岡さん（@little_hand_s）向かいに Yahoo! の辻さん（@crossroad0201）が座られていたので、思い切って上述の疑問をぶちまけました。

私：

「私はDDD初心者で、今日、みなさんの発表を聞いていて感じたのですが、これって純粋にオブジェクト指向をするってことじゃないんですか？

松岡さん、辻さん：

「そのとおりだと思います」

このときの嬉しさ。我が意を得たり。

さらに補足してくれるスマートな松岡さん。

Web アプリケーションなのでややこしくなるんですよ。スタンドアローンアプリなら自然とDDDになるんです。

なるほど。めちゃくちゃわかりやすい解説。さらに松岡さんはこう続けます。

要は、高凝集で疎結合を目指していればいいんですよ。

インゲージでは今、自社サービスを Ruby（Rails）で開発しているので質問。

「松岡さん、やはり DDD と Ruby は相性よくないんですかね？

松岡さん

「よくないと思いますね」

なるほど。確かに今日の話を聞く限りは、DDD は型安全でないと実装できない・・・とは言ってないものの、型安全であるほうが望ましいだろうなと思っていました。この1点だけでもRubyなどのLLは不向きなのかなと思います。

また、Ruby on Rails はそもそも DDD が必要ではないようなサービスに向いているのでは？という意見もありました。適材適所ということでしょうか？

ただ、私は「Ruby on Rails にだって、DDD の考え方はとても重要ではないか。何か活用できるはず」と思っていました。

Ruby on Rails の構成

DDD と Ruby on Rails が相性が悪いということについて、私の今の理解はこうです。

Webアプリケーションというのは、結局のところ、画面からの入力（ほとんどの場合テキスト）をデータベース（SQLレベルではテキスト）に渡す作業ばかりです。

Rails では、画面からの入力は Controller クラスが行い、Controller クラスはデータベースのテーブルの1対1に対応した Model（Rails の文脈の Model）クラスを通じてデータベースの書き込みや読み込みを行うわけです。

つまり、

画面→ Controller → Model → RDBMS

ということになります。ここでは、View はちょっと割愛します。つまりこうなると、ビジネスロジックを書くのは、Controller か Model になり、Fat Controller になるか、Fat Model になるかの道しかない。これはDDD的にうまくない。HTTPリクエストに依存している Controller層とデータベースの永続化を担う Model のどちらからがビジネスロジック（ドメインロジック？）も担うのは確かにおかしい。

ただ、なんとなく、ビジネスロジックをこの間に持たせることがうまくいけば、DDD 的なやり方に近づくのではないかなと思っていました。（上記の理解は間違っているかもしれないです）

まさにこれを考えていたときに、このブログが公開されました。

engineer.crowdworks.jp

すごい。タイムリー。ちょうどこういうことを考えていました。