感想「Beautiful Development ソフトウェアの核心にある複雑さに立ち向かう」
4月9日 Beautiful Development ソフトウェアの核心にある複雑さに立ち向かう(東京都)
とても楽しい、ためになるイベントでした。
場を作ってくれた参加した全ての方に感謝します。
どんなイベント?
- DDD (Domain Driven Design) という設計手法をテーマにしたいろんな記念イベント
- 2003年に出版されていた書籍の邦訳が2011/4/9に出版された記念
- 2011/4/12に開催されるQConに原著者のEric Evanceが来日する記念の前夜祭
- 2011/3/11の東北関東大震災後に開催を自粛していたDevloveの再起動の記念
- 検索キーワードは "devlove0409"
なんで参加したの?
主に興味本位です。
どうしても必要な知識なのに参加できなかった方は残念でした。
- DDDについての話が聞いてみたかった
- 技術的に卓越してる知人の方が参加するようなので便乗した
どんな内容だった?
マルチトラック進行 (陽の巻、陰の巻それぞれで 30分x4) だったので、ずっと陰の巻に参加してました。
オープニング
- id:papanda さんが開催の経緯を語る
- 懇親会の最後に発生したキャッチセールスのような 4tate 勧誘につながってた
- id:digitalsoul さんが DDD 原著出版から DDD 邦訳出版までの経緯をダイジェスト形式で紹介
- 許容するまでの期間が長すぎて「DDD難民の発生」、「DDD に対する憧憬が崇拝に変容」といった事態が発生
DDD+Scala (id:j5ik2o さん)
- http://www.devlove.org/past-beneficiaries/devlove_dddで翻訳事情を知ってレビューに介入
- 「エリック・エヴァンスのドメイン駆動設計」 を献本していただきました - じゅんいち☆かとうの技術日誌でその当時の事情を説明されてました
- Scala の言語説明を駆け足で
- 後で時間切れになったことを考えると省いていただいてもよかったですね
- DDD 2 部 building blocks の実装例を Scala で
- 抽象概念をほぼそのままコードにできる感じでした
- これは Scala でしか書けないというものは無かったようにも思います
- Scala で DDD の DSL
- 時間切れでここまで辿り着けませんでしたね…
- 個人的には一番聞いてみたかったのですが、懇親会とかでも聞き逃してしまった
Deceptive なんとか DDD (角田直行さん)
- DDD との関係についてご自身の読書経歴から説明
- FrontPage - Java EE勉強会で DDD を読んでたときの参加者数グラフ
- 読み手の心の折れっぷりが見えたようで面白かったです
- 一回目:40人近く
- 二回目:30人以下に (脱落者が増えてきた!)
- 三回目以降:10人ちょい
- 最終回:20人弱に (まとめだけ聞きたい人が来た?)
- 読み手の心の折れっぷりが見えたようで面白かったです
- 邦訳をAM5:00までかけて全部読んできた
- 概念的な文章が多くコードが少ないのでわりと大変
- DDD はアジャイル開発が前提になってる
- 東京で「アジャイル開発やってる会社」は @kdmsnr さんの人脈を持ってしても 2 社くらいしか見当たらない
- 厳しいなー
- ソフトウェアの核心にある複雑さに立ち向かう エリック・エヴァンスのドメイン駆動設計 | SEshop.com | 翔泳社の通販の「本書で学べること」の読み方
- 「○○させる」は「○○しましょう」だった!
- 私達が本当に知りたかったのは、「どうやって○○するか?」だよね
- 挫折しない DDD の読み方
- 優先度を付けるとこんな感じ "1部 > 4部 >> 2、3部"
- 1部 (60page)、4部 (p342、p500-p502) これなら読めるでしょ?
- DDD 実践例
- 角田さんのところではいい感じらしい
- DDD Sample に注意せよ
- CodePlex Archiveとかたくさんあるが鵜呑みは厳禁
- クラスの名前を変えたら DDD なのか ? そんなことないだろう
- チーム内でコアドメインの理解が無ければそんなことしても無意味
- 現実的な DDD の始め方
- Q.顧客の組織が縦割りすぎて言葉の意味が統一できなくて困ってるがシステムで対応するべきでしょうか?
- A.一概には言えないけど諦めちゃってもいいと思う
- Q.社内でDDD勉強会してるので優先度は同意できるけど 2部のレイヤードアーキテクチャはおさえておくべきでは?
- A.Yes。チームを混乱させないよう皆が同意しながら進むのがよいと思います
- Q.ユビキタス言語を一番に勧めるのは何故?
- A.これが本質だと思ったから
残念なプロジェクトの DDD (@bikisuke さん)
見せられないよ!
ブレイクスルーと文学 (佐藤 匡剛 さん)
文学に対する知見があまりにも足りてなくて字面以上のことを理解できませんでした。
興味のある方は発表資料を見つけていただくか、ソシュール、ハイデガー、ウィトゲンシュタインといった人物に、
エリック・エヴァンスを並べてみた結果どうなるかを考察すればよいと思います。
キーノート (id:digitalsou さん)
- 4部の「戦略的設計」の導入
- 残り1/4かと思いきや分量だけなら1/3くらいはある挫折ポイント
- スクラムによるドメイン駆動設計 - Digital Romanticismに同じテーマの説明があります
懇親会+LT
- ビアバーッシュ
- あちこちで DDD の議論してる小集団ができてたりして、よいわいがやでした
- @oota_ken さんの LT はやばすぎた
- @kosei さんの LT 見て涙腺が一部決壊した。自分に何ができるだろう
- id:t-wada さんのハイフンがアンスコに変わる直前という貴重な瞬間を目撃した
- 4tate ビデオメッセージに参加したからこそ、長々と記録を書いている
面白かったこと3つ
DDD に対する期待感
観測範囲は devlove 界隈に限定されているのですが、10月27日 Beautiful Development ~ソフトウェアのつくりかた~(東京都)の参加者が40人、今回が 88 人という数字は意外なものでした。
私は mixi の DDD 難民コミュは知らないし、デブサミの DDD 難民イベントにも未参加なので、それらの経験者がほとんどなのかもしれません。
これだけの人々がレガシーコードや謎のプロジェクト管理に悩まされながらも意欲的に学ぼうとしている。
すごいですよねぇ。
DDD の 3 つ目の D は Development ではなく Design
今日聴いた話から、私はこんな感想を持ちました。
TDD は不安を解消していくメッセージがはっきりしてるけど、DDD は本質を追求していくというメッセージが自分としては不安を駆り立てる
id:t-wada さんにこの疑問をぶつけたら、あっさりと答えをいただきました。
TDD も DDD も変更は不可避であるという前提の元に立てられた考え方なので、逆を向いてるわけじゃないよ
自分なりに整理するとこうなりました。安心できた。
- ドメインモデルに「唯一の解が存在するわけではない」だけであって、「ある時点での最適解が存在する」ことを否定しているわけではない
- だからこそ顧客と対話し、モデルをより深く理解し、設計を洗練していくことができる
今後やること3つ
- 4tate のビデオメッセージに出してしまったし、なるべく勉強会レポート書くようにします
- DDD の読み方は角田さんスタイルに学ぶ
- ユビキタス言語と実装の一貫性になんか思うところがあるので考える