connpass
http://ddd-alliance.connpass.com/event/18959/
Togetter
http://togetter.com/li/869354
場所は銀座の歌舞伎座タワーあるドワンゴさんです。
参加申込は満員御礼、９０人くらいかな。
DDDと言えばこの本。まさしく鈍器！
エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)
posted with amazlet at 15.09.02
エリック・エヴァンス
翔泳社
売り上げランキング: 40,045
翔泳社
売り上げランキング: 40,045
DDDに関する講演はこれまで、５～６回くらいは参加したでしょうか。
増田さんのDDDに関する講演も３～４回は聞いた覚えがあります。いくつかはブログにも書きました。
あと、@naopi さん主催のDDD本読書会(羊)にも参加してました。
初回に参加したときのブログはこちら ⇒ 2013/6/8(土) 「DDD本 読書会(羊) #0」に参加しました
この読書会は基本毎月開催で２年くらいかかったんですが、全１７回＋α、無事読み終えましたｗ
あと長期休暇とかにも１日１章ずつ読んだりと、それなりにDDD本は読んだ気がします。
ただ、やっぱ難しいトコが多くて、とてもじゃないけど「DDDは理解した」という状態には至っていません・・・
そんなわけで今回のイベントにも参加することにしたのです。
ちなみに申込者は１３０人以上いたと思いますが、私が一番早かった！
第1週（1章～7章）DDDの基本を理解する
- 第1部 ドメイン駆動設計の3原則 （1章、2章、3章）
- 第2部 ドメイン駆動設計のグッドパーツ （4章～7章）
３週連続DDDその１ from 増田 亨
大事なことはスライドに書いてあるので、口頭で補足説明があった部分を中心に個人メモ。
---
■ 増田さんのDDDに関する取り組み （P.6）
- 最初はDDDがよく分からなかったが、分からないながらも現場でやりはじめた。
- 一番最初のころは読み落としていた、勘違いしていたことがいっぱいあった。
- 自分の経験から思っていたこととエヴァンスの考えが違っていた。
- そういう気付きがだいぶあった。
- 8年やってきて成長できたかな。
■ エヴァンスの取り組み （P.10）
- エヴァンスはケント・ベックやマーチン・ファウラーと一緒に仕事してきたので、オブジェクト指向やエクストリームプログラミングを組み合わせてやってきた。
- 本を読んで吸収しようと思った時に、この２つなんだ、というのはキーになる。この文脈で読むと理解できることがあった。
■ 勉強になった本 （P.15）
- 「リファクタリング」に勝るものはない。「実装パターン」もコードの話ばかり。この2冊はとにかくやった。
 新装版 リファクタリング―既存のコードを安全に改善する― (OBJECT TECHNOLOGY SERIES) posted with amazlet at 15.09.06 Martin Fowler オーム社 売り上げランキング: 16,529 |
 ケント・ベック Kent Beck ピアソンエデュケーション 売り上げランキング: 93,585 |
- 「オブジェクトデザイン」がオブジェクト指向の本の中で一番印象に残った。
 オブジェクトデザイン (Object Oriented SELECTION) posted with amazlet at 15.09.06 レベッカ・ワーフスブラック アラン・マクキーン 翔泳社 売り上げランキング: 232,350 |
- XPは勉強しなおしている真っ最中。新訳で読んでる。
 エクストリームプログラミング posted with amazlet at 15.09.06 ケント ベック シンシア アンドレス オーム社 売り上げランキング: 23,663 |
- XP本の参考文献に上がってる「わびさびを読み解く」という本は、ウォーターフォール的な物事の計画の立て方と、XPの人間の活動に合わせたソフトウェア開発のやりかたが書いてあって、すごく参考になる。
- 哲学的なことをが書いてあるわけではない。ぜひ読んでください。
 Wabi-Sabi わびさびを読み解く for Artists, Designers, Poets & Philosophers posted with amazlet at 15.09.06 レナード・コーレン ビー・エヌ・エヌ新社 売り上げランキング: 28,712 |
■ 「適応型」のソフトウェア開発 （P.17）
- オブジェクト指向とエクストリームプログラミング、２つは車の両輪。
- オブジェクト指向の変更容易性、エクストリームプログラミングの変化適応性。
- 前者が後者を支えている。同じ哲学からでてきてるんだろうな、と思う。
- 相互に補強しあう関係。
■ 「適応型」のソフトウェア開発 （P.21）
(1) 予測型
- ソフトウェアの最終形を早い段階で早い段階に厳密に定義して、そこへの近づき方を重視するスタイルが予測型。
- ビル開発なんかもこんな感じ。ただ最近のソフトウェア開発では「それって、どうなの？」ってのはある。
(2) 反復・漸進型
- 予測型の改善策として出てきたのが反復漸進型。代表はRUP。
- 遂行フェーズでリスクを潰す。
- これも大きくみれば計画型。計画して、着地点に到達する。リスク駆動で精緻化していく。
- これとアジャイルはまったく違っている、と個人的に思っている。この理解がDDDのキーだと思っている。
(3) 適応型
- XPは変化に適応しながら育てていく、という点が重要で、DDDのポイント。適応型に相当重きが置かれている。
- 適応型も、最終形はざっくり考える。でも最初から全部わかるわけがない。
- ドライブのメタファ。目的地は決まっている。ルールやスピードは走りながら調整していく。
- 天候が変わったり、ドライブ中に見つけた場所に寄り道したり。
- 「関係者が納得すればそれでいいじゃない？」という考え方。
- みんなで合意してれば、当初の予定と全然違うところに到着したっていいじゃない。
- 人間のリズムを重要視している。そういうふうにしたほうが人間的なエネルギーが出るよね。
■ YAXP（もう一つのXP） （P.23）
- YAXP(Yet Another XP)というのは「もうひとつのXP」。自分が名付けた言葉。
- とにかく動くソフトウェアを作り続ける、という、究極のXP。曖昧な要求、口約束、なるはや、追加と修正の嵐・・・
- 自分のこまでの経験で、口頭で依頼を受けた開発の最高額は６０００万円だった。
- 適用型のソフトウェア開発では当たり前。DDDの良い実践の場。
■ 抽象データ型／段階的な抽象化 人間の発想に近づける （P.27）
- Javaにはintとかshortとか、言語仕様レベルのレイヤがある。それを使って日付を表現しようとすればできる。
- そうじゃなく、人間の日付という概念に、コンピュータの要素をラップする形で近づけたのがLocalDateクラス。
- 言語仕様レベルのレイヤから、人間のやりたいことに近づけていくのが段階的な抽象化。
- DDDは徹底的にこれをやる。関心があるものだけ記述する。
■ OO + XP ＝ ドメイン駆動設計？ （P.28）
- 半分はYESかな。
- DDDは、OOの最終形。OOのコミュニティで評価が高い。
- エリック・エヴァンスは、「OOとXPの、それぞれの設計で強調しているところに名前をつけたのがDDDである」と言っている。
- OOが忘れたものを思い出させてくれる。
■ 「ドメイン駆動設計」の理解の鍵 （P.30）
- ドキュメントより会話、は精神論として知られているが、ドキュメントは「過去のもの」という点も重要。
- チームで合意をとって進むのに大事なのは「言葉」なんだよね。
- 毎日言葉を使って会話していくことで理解を共有していく。
- OOとXPが鍵なんだ、と気づいてから、DDD本の「まえがき」に納得感が生まれた。
■ 「ドメイン駆動設計」の３原則 （P.32）
- １～３章の理解と実践がDDDのすべて。
- １～３章にもでてくる話を自分なりに実践するだけでも価値は出てくる。
■ ドメイン （P.33）
- ドメインとは、ソフトウェアを利用する人たちの「活動」と「関心事」。
- ソフトウェアを実際に使う側の人たちはコンピュータに興味があるわけではなく、ビジネスや業務上の成果が関心事。
- それを理解したうえでソフトウェアを作りに行くんだ。
- 技術者にとってドメインは画面仕様書とか機能一覧とか。そこにドメインの言葉は確かに出てくる。でも、そこの言葉と利用者側にすごくギャップがあるから、ユーザ側にもっと切り込んでいかないといけない。
■ ドメインのモデリング （P.36）
- 利用する人たちの「活動」と「関心事」を要約する。
- 軸となる関心事をいかに見つけに行って、「これが嬉しいんですよね」と、いかに要約して説明するか。
- 「要約」がモデリングのキモ。
- 「要点」はなんだんだ、骨格はなんなんだ、と探しに行くことがモデリング。
- 本質的でないものを削る力は、発見する力よりも難しい。理解できるようになるには、相当ドメインの知識を増やさないといけない。
- ドメインエキスパートは、何か重要かをわかりやすく説明はしてくれない。
- わかっていても、言語化できるかは別能力。だけど、間違っていたら正すことはできる。
- なのでドメインエキスパートに話しかけて、フィードバックを得ることが重要。
- 耳を傾ければしゃべってくれるのではない、我々が探しにいかなければならない。
- ユーザの企画書は怪しい。綺麗事や官僚的な作文が多い。そこを確認しにいくのもエンジニアの仕事の１つ。
- ユーザが何に感心を持って活動しているのか、を要約できる力がDDDを実践していくうえでの一番のスキル。
- 言葉とかスケットとかコードとか、目や耳で感知できる形にして、チームで共有する。
■ 第１章 （ドメインの）知識を噛み砕く （P.42）
- いろんなメディアを使いながら知識を噛み砕く、と本には書いてある。
- まず知識を噛み砕く。出発点ですぐにソフトウェアを作り始めてはいけない。
- P.49のまとめスライドに書いてあることができていれば、DDDができているということ。
■ 第２章 言葉を使った意思の伝達 （P.51）
- UMLでなく言葉でチームに浸透させる。設計ドキュメントやレビューの代わりに言葉で伝える。
■ ユビキタス言語 （P.52）
- いつでも、どこでも、誰とでも。
- 「同じ言葉で語れ」ということよりも「いつでも話すこと」が大事。技術者同士での会話でもユビキタス言語を使う。
- ある単語が出てきたとしても、同じ意味とは限らない。これを発見して、１つの言葉を同じ意味に揃えることが大事。
- 「おまえのいってる○○って、こーゆうこと？」と突っ込む。
- なんかおまえのいってること違うな、と思ったら突っ込んで確認することが大事。
- ドメインモデルはユビキタス言語の全部じゃない。
- ユビキタス言語は５００とかに最終的にはなる。ユビキタス言語のコアを抜き出したものがドメインモデルになる。
■ 声に出してモデリングする （P.53）
- しゃべる、聞く、がコスト低いし、感覚的に「おかしい」と気づくのに一番よい。読んだり書くよりも格段に感度が高い。なのでそれを使いましょう。
■ 一つのチームに一つの言語 （P.54）
- 第4部の「境界づけられたコンテキスト」の基本原理となっている。
- 第4部の「継続的な統合」、も、CIという意味ではなく、言葉の不一致を継続的に統一していきなさい、ということ。どう見つけて統合していくかに言及している。
- このあたりにDDDの言葉のわかりにくさがあるかもしれない。
■ 言葉たいせつ （P.56）
- 開発者が、利用者の「重要な関心事」をよどみなく語り始める。こうなれば安心。プロジェクトに大きな問題は起こらない。
- 開発者が技術用語しか使わない恐怖感。開発者が何を作ってるかわからない恐怖感。大外ししている可能性が０ではない恐怖感。
■ 第3章 モデルと実装を結びつける （P.57～」
- モデルは分析に使えるだけでなく、設計に使えないといけない。
■ 第2部 モデル駆動設計の構成要素 （P.66）
２部は基礎練習。どんな状況でもできるようにしなければならない。
■ レイヤー化アーキテクチャ （P.68）
- ドメイン層を分離し、すべての層がドメイン層に依存するようにする。
- これを表面的に実装するのは難しくない。問題なのは表面的な分離でなく、ドメインロジックがコントローラー層やページ記述に染み出したりした場合。
- 状態の判断がビューに染み出してたら、ドメイン層に持っていかなければならない。
- そいういう作業をすることによってはじめてドメイン層に知識が集まる。
- いかに検知してドメイン層に持ち込むか、リファクタリングを緊密に実施するか、が重要。
- SQLのSELECT文で、WHERE句でイコール条件を使って区分を判定していたりしてたら、ドメイン層からドメインが抜け落ちているシグナル。
■ ２ステップビュー （P.72）
- エンタープライズアーキテクチャパターンに登場する。
 エンタープライズ アプリケーションアーキテクチャパターン (Object Oriented Selection) posted with amazlet at 15.09.06 マーチン・ファウラー 翔泳社 売り上げランキング: 97,624 |
- STEP1はドメインオブジェクトが論理構造を返す。
- <tr>といったHTMLタグは見栄えのビューなので、STEP1とは分ける。
- STEP1で論理構造をマップとしてまず持たせて、STEP2で、マップから物理構造に変換するための変換クラスを作る。
- 全部ビューで組み立てるのではなく、可能な限りドメインオブジェクトに持たせる。
■ 第4章まとめ （P.75）
- ポイントは、ドメイン層からの漏れ出しにいかに気づいて、いかに防ぐか。
■ 第5章 「モデル」をプログラムで表現する
- モデルとコードの一致は難しい。
- 5章は表面的なことで、出発点。DDDなら誰でもやっている。
■ 何が違うのか？ （P.80）
- 左のクラス図のままだと、モデルとコードを一致させにくくなる。
- クラス図には、顧客と住所はいつも一緒に考えないといけないんだ、という「集約」を表現したい。
- 左のクラス図のほうがシンプル。
- でも右のクラス図のほうが、「住所」という関心事があるのならクラスとして分離し、面倒な「関連」と「集約」を背負い込んででも、モデルとコードを一致させよう、という意思が読み取れる。
- この違いが、5章のすべて。
- 左のクラス図ほうが楽。でも、右のクラス図はめんどくさくなるけど、モデルとコードが一致させられれるようになる。
- 左のクラス図は、下３つのフィールドが「住所」だ、という情報がどこにも入ってない。
- 右のクラス図は、その３つが「住所」だと明確に表現されている。
- こーゆう感覚をチームで自然に共有できるようになるかがDDD実践の鍵。
- 住所をクラスとして分離することで、「住所が無い時はどうするんだっけ？」、「住所が複数ある時はどうするんだっけ？」という議論が出てくる。
- この思想と設計は、どんなにめんどくさくても、ロスタイムのへろへろな状態でもやるんだ。
■ 値オブジェクト（Value Objects） （P.83）
- 関心事を表現する独自の型を作り、メソッドの引数や型に指定することで、メソッドを知識豊かに表現する。
■ エンティティ（Entity） （P.84）
- エンティティ＝データベース、という考えが染み付いてるので、エンティティは太りがち。
- エンティティは、「識別」という利用者の関心事に集中する。
- とことんスリムにする。
- Valueオブジェクトは、関心事の抽出を繰り返すことによって見えてくる。ここでは一意識別の話は忘れてください。
- 人間が同姓同名にぶつかった時にどう判断するかを掘り下げていくことによってドメインの理解が深まる。
■ ドメイン層のサービス （P.85）
- 「サービス」を覚えたばかりのエンジニアは、なんでも「～Policy」というクラスに分離したがるが、これは危険。手続き型になっちゃう。
- 回避策としては、メソッドの引数と戻り値の型を「ドメインオブジェクト」にすること。そこにlongとかStringとか使わない。
■ ファーストクラスコレクション （P.88）
- コレクションをラッピングしたドメインオブジェクトを定義することで、「一覧」から関心事を取り出すようにする。
- ユーザの関心事と一致させられる。
■ モジュール（Packages） （P.90）
- モジュールは本当に重要なモデリング要素なので、名前や構造を変える作業は積極的にやってください。
- コードを、利用する人たちの構造に沿って整理すること。
■ 第6章 ドメインオブジェクトのライフサイクル （P.94）
- 「集約」、「ファクトリ」、「リポジトリ」の３つは、ライフサイクルや整合性が強調されている。
- なぜそれらを問題視しているかというと、モデルに余計な心配が入ってきてモデルとコードの整合が崩れやすいから、「集約」、「ファクトリ」、「リポジトリ」の３つを使うといいんだよ、と言っている。
- ドメインの関心事から生まれる設計でなく、関心を守るために必要なものが「集約」、「ファクトリ」、「リポジトリ」の３つである。
■ 第7章 言語を使用する：応用例
- 7章は実践例。ぜひ読み直して欲しい。
- 流れが12ステップある。この流れを意識するとだいぶ楽になる。
- 各ステップで何をやってるかがわかると、モデルを育てる、歩調を合わせる、というのがだいぶわかってくる。
- まず、アプリケーション層を導入する、というのを一番最初（ステップ２）でやっている。ここでドメイン層の議論を機能の視点から隔離している。
- アプリケーション層は、機能からドメインを分離する。ここは勉強する価値が非常に高い。
- 入出力項目の定義はほとんど登場しない。それらを固めるアプローチはDDDではない。ソフトウェア開発では入出力項目の定義はぜんぜんアリだけど、DDDではない。
- 関連・集約・リポジトリは、7章の具体例をよく読んでください。6章より7章の例のほうがわかりやすい。
★感想：
この勉強会に参加することが決まってから、じゃあ１～７章をもう一度読みなおしてから勉強会に参加しよう！という気持ちになりました。
もちろん７章をじっくり読むには時間が足りなかったのですが、それでも太字の部分を中心に拾い読みしつつ、一通り目を通してから参加しました。
そいういう意味で、この勉強会は再度勉強しなおすチャンスを与えてくれました。
その副産物の効果がとても大きく、復習のモチベーションに繋がったのはとてもありがたかったです。
あと、増田さんの説明も大変わかりやすく、新しい気づきもたくさん得ることができました。
#DDDAlliance でXPの重要性について増田さんが力説されていた矢先、帰宅したらAmazonから #xpe2nd が届いていた。これは運命。 pic.twitter.com/8134aRS6aZ
— makopi23 (@makopi23) 2015, 9月 2第２週も当選したので参加する予定です。
増田さん始め関係者の皆様、ありがとうございました。
