「Developers Summit 2015」に参加してきました - 其の壱 - 「ドメイン駆動設計再入門」

2015/2/19(木)～2/20(金) 「Developers Summit 2015」に参加してきました。

公式サイト
http://event.shoeisha.jp/devsumi/20150219

場所は目黒雅叙園です。
参加者は数百人規模・・・何人くらいなんだろ？

今年もなんとか仕事を調整し、2/19(木)は午後から、2/20(金)は朝から丸１日、参加してきました。
おかげさまで、ここ数年は毎年参加できてます。

会場受付付近にある翔泳社＆オライリーの書籍ブースの写真１枚。


やっぱ、こーゆー場にくるとエンジニアとしてワクワクしますねー
さて、いつもどおり復習のブログを書くにあたり、まずは以下セッションの聴講メモを最初に書くことにしました。

• 【20-C-3】　ドメイン駆動設計再入門
  • http://event.shoeisha.jp/devsumi/20150219/session/692/

というのも明日2/22(日)にDDD読書会があるのですが、主催の @naopi さんから軽く紹介をお願いされたのです。

• DDD本 読書会(羊) #16
  • http://dddsheep.connpass.com/event/11872/

---

■ 【20-C-3】　ドメイン駆動設計再入門
和智 右桂 氏〔グロースエクスパートナーズ〕

ドメイン駆動設計再入門 from Yukei Wachi

• Togetter： http://togetter.com/li/784406?page=1

和智さんのDDDに関する講演は他でも何回か聞いたことあります。
以前、書籍に和智さんのサインも戴きました。
今回も、いつもの丁寧で謙虚な姿勢、そして笑顔、健在でございました。

以下、自分の復習用に、個人メモ。
---

■ モデルとは　（P.7～）

• 「モデル」とは何か、あなたは後輩に説明できますか？
  • 「モデル」という用語をいろんな人がいろんな意味で使っている。
• DDDを読む前提だと、1979年のTrygve Reenskaugの言葉を借りると、「モデルとは知識の表象である」。
  • ※ググってみると、和智さんのブログがヒットした。
  • 　Trygve Reenskaug氏の記事「MODELS - VIEWS - CONTROLLERS」の日本語訳
  • ３０年以上前の1979年に、既にMVCについて議論されていたのが驚き・・・
• でも、この説明は現在のMVCのモデルと若干違う気がしませんか？
• それは、「メンタルモデルを写し取るもの」という考え方。
• MVCは「ビューとモデルを分けましょう」と理解されているが、当時は、「頭の中をコンピュータに写し取る」というものだった。
• 人は自分の業務に対してイメージを持っていて、その頭の中に持っているイメージが「メンタルモデル」である。

■ MVCからDCIへ　（P.10～）

• モデル・ビュー・コントローラ ： モデル・ビュー・コントローラ - Trygve Reenskaug
• DCIアーキテクチャ ： DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien

■ 第１部「ドメインモデルを機能させる」　（P.12）

• 書籍は４部構成となっている。
• 第１部は５００ページ中、９０ページくらいで、けっこう薄い。
• 第１部だけでもぜひ読んでください。DDD本が高いと思ったら、９０ページだけでも立ち読みを・・・ｗ

■ モデルの基本的な用法　（P.13）

 １．モデルと設計の核心の相互作用

• モデルと設計・実装を結びつける
• 分析フェーズでコンサルが難しいパワポを書いて、その後に去っていく、というのは良くない。
• ちゃんと作ったモデルはコードの中まで持ち込みましょう。

 ２．コミュニケーションの基盤

• モデルは実装、設計のためだけではなく、これってどういう業務なのか、という話を客と話すベースになるもの。
• 「ユビキタス言語」は、チーム全員やお客さんが使う用語を統一した共通言語。

 ３．蒸留された知識

• 業務が詳しい人の知識を表現すること。
• モデルはソフトウェアの中核なので、モデルをソフトウェアの中に持ってこよう、というのが基本的な考え方。

• モデルはソフトウェアの中核となり、ビジネスパーソンと開発者をつなぐ。

■ 第２部：　モデル駆動設計の構成要素　（P.16～）

• 第２部がけっこう鬼門。急激に実装寄りの話になるので、読むのが止まりやすい。
• モデルをソフトウェアの中に持ってこよう、ということを具体的に書いている。
  • １．レイヤー化アーキテクチャ
  • ２．ドメインレイヤ内でモデルを実装する
• ざっくり言うと、「ドメイン層とは、モデルが息づく場所」のこと。
• UIとDBの間にレイヤーを切って、そこにオブジェクトを置きましょう。
• P.18のアーキテクチャを作るにはどうすればいいか？のパターンがいくつか書いてある。

■ 第３部：　より深い洞察へ向かうリファクタリング　（P.19～）

• 第３部は、個人的に非常に面白いと思っている。第２部は飛ばしても、第３部は読んで欲しい。
• DDD本を読む順番は、「第１部の次は第３部へ行け」と著者も薦めている。
• 個人的には　第１部　⇒　第３部　⇒　第４部　⇒　第２部　の順で読むのがオススメ。

■ モデルの深化　（P.20～）

 １．時間をかけてモデルは深まっていく

• モデルは作って終わりじゃない。時間をかけて深化していく。継続学習。
• モデリングは「発見のプロセス」である。
• 開発者が拾いきれていないだけでなく、ドメインエキスパートさえも、開発者に説明してモデル化していくと「あれ？おかしいね・・・」と気づくことがある。
• 開発者とドメインエキスパート双方にとって、モデリングは発展のプロセスである。
• モデリングを進めると、ある時、まったく違うモデルに気づいてガラッと変えることがある。それがブレイクスルー。

 ２．深いモデルを作るためのテクニック

• 「暗黙的な概念の明示化」とは、普通に考えていると出てきにくいものをオブジェクトにすること。
• しなやかな設計、先達からの学習、デザインパターン、などが紹介されている。
• 第３部までは、１つのシステムに閉じた話になっている。第４部から、その趣が変わる。

■ 第４部：　戦略的設計　（P.21～）

• モデリングのスケールアップ
  • 第３部までは、１つのシステムや業務をターゲットとしていた。
  • エンタープライズシステムでは、いろんなシステムが連携して動くことになる。それにどうしたらいいか、が書いてあるのが第４部。

 １．モデルの整合性をとる

• モデルの境界設計の話で、他システムとの境界をどうしたらよいかが書いてある。

 ２．蒸留

• フラットなモデルにおいて、大事なトコとそうでないトコがある。モデルから本質を抽出する話が書いてある。

 ３．大規模な構造

• 巨大なシステムをレイヤー化して俯瞰するためにどうすればいいかの話が書いてある。

■ 後に続く本　（P.23～）
モデルを核にしたシステム観を継承している２冊を紹介する。

１．GOOS (2009)

実践テスト駆動開発 テストに導かれてオブジェクト指向ソフトウェアを育てる (Object Oriented SELECTION) (2012/09/14) Steve Freeman、Nat Pryce 他 商品詳細を見る

• オブジェクト指向のシステムを作るには、成長させるには、どうすれば良いかが書いてある。

２．DSL (2010)

ドメイン特化言語 パターンで学ぶDSLのベストプラクティス46項目 (2012/05/02) マーチン ファウラー、Martin Fowler 他 商品詳細を見る

• DSLを作るにはどうすればいいかが書いてある。
• 根底にあるモデル観、システム観はDDDによるところが大きい。
• DSLは抽象的なモデルを作った上で、モデルを操作する言語を提供する。
• DDDでも宣言的な設計を突き詰めると、そうなるんじゃないか。
• 何が言いたいかというと、モデルを取り巻く考えが重要視されているのでは、ということ。

■ DDDの魅力　（P.25～）

• プログラマーにもプロジェクトマネージャにも、DDDは魅力あるんじゃないか。
• というのも、DDDはテクニカルにどうするかというより、業務をちゃんと分析しましょう、という話なので、プログラマーやプロジェクトマネージャ、全エンジニアに共通のテーマだから。

 
 ■ ある抽象度でのモデリングは絶対に必要

• システムを俯瞰して考えるときに第４部の話は重要になってくる。

 ■ソフトウェアの本筋

• モデルをソフトウェアに取り込んでいきましょう。

 
 ■ SIの現場での福音

• ここから怪しい・・・
• プログラマの時に、いいやり方をいろいろ探していてDDDに初めて出会った。
• コードを書くのは好きだったが、DDDはとても魅力だった。
• その時、閉塞感があった。

 ■サイロ

• 会社の縦割り、横割り構造。
• 何かを主張しようとしても、サイロのために上の人に阻まれたり、横にも届かなかったり・・・

 ■ 滝
ウォーターフォールは絶対に必要なプロセスだが、中の人にとっては、必ずしも楽しいものではない。


 ■ 規律

• 上から言われたとおりに作る。何を作るかというと、「トランザクションスクリプト」・・・

---

そういうことのツマラナサを感じる際、お客さんと会話しながら、変化に対応しながら進んでいくというDDDの思考が魅力的だった。


■ バランスが大切　（P.36～）

• DDDって、それぞれのレイヤーにいる方にとって、アピールするものがある。
• でも、それを全体に取り込む時に、全員が幸せになるように「DDDで作ろう！」とすると不幸が始まる。
• バランス大事。

■ モデルをどこまで保つべきか？　（P.38～）

• この絵は、アリスター・コーバーンのユースケースの本からの借用した図。
• 要求を海面まで落とす人と、海面から下へ実装に落とす人に分かれる。
• 業務サイドとエンジニアサイドが共感しあえる場所が、海面。
• それを、海面下に何も考えずに落とそうとすると、不幸が起きる。

■ ドメインレイヤの外側　（P.40～）

• ドメイン層の外側には以下がある。
  • ユーザインタフェース層
  • 永続化層
  • 他システムとの統合層
• DDD、ドメイン層だけに着目していると、上記のような他層の設計から離れてしまい、おろそかになりがち。
• ドメイン層の動きと平行して、他の層と最後に統合しないといけない。これが大変。
• この話は、DDD本にはやりかたが書いてないので、自分たちでちゃんと考えないといけない。

■ すべてを統合する　（P.41～）

• すべての機能は複雑なのか？
• マーチン・ファウラーのPofEAA（エンタープライズ アプリケーションアーキテクチャパターン）に、ロジックの構成方針として２つが紹介されている。
  • １．トランザクションスクリプト　（ユーザの要求を満たす手続き）
  • ２．ドメインモデル　（複雑なロジックをオブジェクト思考で解決する）

エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection) (2005/04/21) マーチン・ファウラー 商品詳細を見る

■　損益分岐点を見極める　（P.44～）

• P.44は、この２つの損益分岐点を表した図。縦軸が「機能追加のコスト」で、横軸が「ロジックの複雑度」を表す。
• この図を見ると、ドメインモデルの線の上がり方は緩やかである。
• 図の右の方だけ見ると「ドメインモデルを採用すればいい」という話になるが、図の一番左に、トランザクションスクリプトの方がドメインモデルよりコストが少ない箇所がある点を忘れてはいけない。
• その割り切りが必要。ロジックが簡単ならトランザクションスクリプトもアリなはず。

■ 複雑さは囲い込む　（P.45～）

• 複雑さは囲い込んで、複雑じゃない箇所はSQLで処理すればいいじゃないか。
• では、複雑なやつとそうでないやつの見極めは、どうやれば？
• 「慣れた人に任せるしかないよね」 byマーチン・ファウラー
• 私も、SQLでさらっとできるならトランザクションスクリプトでやればいいのでは？と個人的には考えている。

■ 何を対象とするのか？　（P.47～）

• 下に落とし込むときに、どこまで落とし込むのか？モデリングの対象ってなににするのか？

■ デザインするのはメンタルモデルだけでいいのか？　（P.48～）

• ドメインモデリングに注力し過ぎると、画面遷移や業務フローにびっくりするくらい考えなくなるようになる・・・。
• システムの外側で起きることへの配慮が、システムの中ばっかり考えていると、すごく抜ける。
• システムの外側まで考えないと、システムの中ばかり作れても、システムとしては動かない。
• 大事なのは、お客さんと同じものを見ること。
• ユーザさんが何を考えて動いているのか、ユーザが見てる世界を一緒に見ないと上手くいかない。

■ 成長するのはモデルだけなのか？　（P.51～）

• システムを取り巻く流れはいっぱいある。企業のビジネスだったり、社会の状況だったり。
• これらをきちんと考えないといけない。
• モデルが精緻に深まっていくだけでなく、システム全体として成長していくことが大事。
• システムをどう育てていくかまで考えてフィードバックループを設計しないといけない。
• システムだけでなく開発チームも成長していく。両方を合わせて考えていかないといけない。

■ まとめ　（P.56～）

• 今日はドメインモデリングの内側と外側について話した。これはDDD本には書かれていない。
• でも、なぜDDD本に書いてないのか、というのは筋違い。
• DDDは素晴らしい構想。
• ただ、DDDの内側で考えていても、システム開発の観点からだと上手く行かないので、システム全体で考えよう。
• DDDは難易度が高いものに対して何をやればいいかを教えてくれるもの。

■ さいごに　（P.58～）

• 世界に対するエンジニアの貢献はコードの優劣では決まらない。
• 業務ロジックを書くというのは比較的地味。
• でも、ちゃんと分析して、ユーザと創り上げるのは価値があるし、やりがいがある。
• 業務エンジニアに対する応援として１つ言えるのは、「コードを見るだけでは優劣は決まらない」ということ。
• トランザクションスクリプトだからダメ、ということはない。
• エンジニアが社会に貢献するのは「システムが何を達成できているか」であって、「中のコードの優劣や難易度」ではない。
• システムを通じて社会に貢献することが大事。

---

★感想：
和智さん、やっぱ紳士というか真摯だなぁ、と。
物腰も柔らかく、話は明快でポイントが押さえられており、自分の主張もきちんと入ってて、エモい話で締める。
この講演を聞いて、も一回、１からDDD本を読み直したくなりました。

ちょうど週末、DDD本の読書会もあります。そこの貴方、ご一緒にいかがっすか～

今週末にDDDの読書会ありますー #devsumiC / DDD本 読書会(羊) #16 http://t.co/5GC2eor7JH #DDDSheep

— makopi23 (@makopi23) 2015, 2月 20

残りの講演についても、自分の復習のためブログにメモ書いていこうと思います。
続きは後日～