DoorKeeper
http://ddd-alliance.connpass.com/event/18961/
Togetter
http://togetter.com/li/873126
先週行われた第１週も参加しました。そんとき書いたブログはこちら。
2015/9/2(水) 「DDD Alliance! 3週連続DDD 第1週」に参加しました
今回は台風の影響でどうなることやら、と思いましたが、無事開催されてよかったです。
でも、大雨で日本あちこち大変だったようですね・・・
というわけで、今回も自分の復習のため、口頭説明部分を中心に当日取ったメモを書き起こしてみる。
第2週（8章～13章）深いモデルの探求
3週連続ddd その２ 深いモデルの探求 from 増田 亨
第1週のおさらい
■ 抽象データ型／段階的な抽象化人間の発想に近づける （P.7）
- 人間の発想に近づけるというのは、今日の第3部でもポイントになる。
- 汎用的なLocalDateクラスじゃなくて、誕生日に限定した独自定義クラス（DateOfBirth)まで持っていく。
■ 俯瞰 （P.9）
- 第１部 ドメインモデルを機能させる
- ドメインは大切だね、じゃなくて、エヴァンスはもっと極端なことを言っている。
- ドメインモデルを中心にすべてを組み立てる。
- 第２部 モデル駆動設計の構成要素
- 第２部は基本スキル。必要最低限。でも、いくら第２部を実践してもDDDのメリットや効果は出てこない。
- 3週連続でしゃべろうと思ったのは、この辺を話そうかな、と思ったから。第2部に時間をとられて話せない部分を話したかった。
- 第３部 より深い洞察へ向かうリファクタリング
- ドメインモデルが現場に役立つのは、第3部を頑張った結果として出てくる。
- 第2部でリポジトリとか実践しても、ぜんぜん恩恵はない。
■ 主題：モデルを活用する （P.11）
- この図がDDDのキモ。
- 膨大な技術を噛み砕く、自分から集めていく。集めるだけでなく、鋭く説明するにはどうすればいいんだ、に切り込む。
■ ドメイン （P.12）
- ドメインモデルは、要約したもの。本当に重要な語彙に絞ったものがドメインモデル。
- ドメインモデルがコードになってるのは、ドメイン層の５％とかのコア。ちゃんと要約しにいかなければならない。
- ドメイン層全体がドメインモデルというわけではない。
- 狭い範囲を深堀する、という考えは前提知識として持っていたほうがいい。
■ ドメインとソフトウェア （P.13）
- 自分たちは右下の「ソフトウェア」に関心がいく。
- 「ソフトウェア」の左上の境界に現れる画面設計書とかにドメインの言葉が出てくる。
- でも、それ以外の活動でどう関心事が出てくるか、自分から外に出て、取りに行かなければならない。
- なぜその人が活動しているか、その目的とか経緯とかまで思いを馳せることが重要。
- 外に広げれば広げるほど楽になる。
- ここまで知れば楽になる、じゃなくて、どんどん外に行って、動機とか背景まで知りに行ったほうがわかりやすくなるかなと思っている。
■ モデル （P.14）
- 大変なのは本質的でないものを削る力。判断できるようになるには、相当知識がないとできない。
- どちらかを選ばないといけないのに選べない、という状況は、自分の知識不足なだけ。
- 何が重要かを追い求めるが大事。
- 厳密に組み立てる力は、ソフトウェアは厳密にしないと破綻するので、ほっといてもフィードバックがかかるはず。それよりも削る力の方が難しい。
■ 第２章 コミュニケーションと言葉の使用 （P.17）
- ドキュメントを書くくらいなら、聞けばいいじゃん。
- ただ、残しておいたほうがいい情報はドキュメントにすることはある。
- ただ、それは厳選する。大事な情報はソースコードに表現されているはず。
- ユビキタス言語は、「いつでも、どこでも、だれとでも」。エンジニア同士の会話でさえも、お客さんと使うような共通言語を使うべき。
■ 第３章 モデルと実装を結びつける （P.19）
- DDDでは、モデルはコードに落とす前の作業、ではない。モデルを書いてても、常にコードを考えろ。
- 具体的に論理的に常に考えてないから、すぐにコードに落とせないんだ。
- コードを書く人がドメインを深く理解することが最も効果的。
- ドメインの言葉を使ってるエンジニアのほうが、スキル優れているエンジニアよりいいものを作る。一緒にやってて安心感がある。
- １～３章を実践することがドメイン駆動設計。それができれば、第２部以降はHow Toに過ぎない。やりかたは他にたくさんある。
■ 【広告】DDDの３原則を体験的に学ぶ （P.21）
- 実践のワークショップをやる。 http://ddd-alliance0002.peatix.com
- 本の実践ではない。
- 要約力を体験する。
- 苦労せず楽しくドメインを学ぶにはどういうアプローチがあるか体験してみる
- UMLとかではなく、言葉とラフスケッチを使ってモデリングする。クラス設計に練り上げる。
■ 第２部のおさらい モデル駆動設計の構成要素 （P.22～）
- 主題は、モデルと実装の一致なんです。
- モデルを熟知していても、コードと乖離することはよくある。非常に難しい。
- そこが不一致になると的外れで構造がねじれたソフトウェアになる可能性が高くなる。変化に適応できなくなる。
- とにかくモデル（主要な概念）がコード上にあらわれているようにする。それがDDD。
- そこに切り込むのが今日の第３部のテーマ。
■ 第４章 ドメインを隔離する （P.25）
- プレゼンテーション層とかアプリケーション層とかデータソース層に、ちょっと修正でIF文とかが入りやすい。
- そうじゃなく、ドメイン層に集めること。
- 大切なのは、その３層に紛れ込んでくるドメイン知識をドメイン層に徹底的に移していくこと。
■ 第５章 ソフトウェアで表現されたモデル （P.27）
- 書籍の図5.6にValueオブジェクトのクラス図が出てくる。5章はこれが理解できるかどうかがすべて。
- 住所という概念をクラスとして切り出す。ただし、２つで１つだよ、という集約を意識しなければならなくなる。
- そのトレードオフを相当DDDは振り切っている。関心事ならば、クラスとして分離しろ。
- 左のクラス図の発想でいる限り、第3部の話は理解できない。
- 左と右のクラス図の差は非常に大きい。狙ってるのは右のクラス図なんだ。
■ 第６章 ドメインオブジェクトのライフサイクル （P.29）
- オブジェクトをDBに入れて取り出す、というライフサイクル管理は、別のクラスに担当させることによって、ユーザの関心事をシャープに表現しやすくなる。
- それらは外出にしましょう。
- 本質は、ドメイン層をピュアに保つための考えの一つ、ということ。
■ 第７章 より実戦に近い練習 （P.30）
- 第2部の理解度チェックとして、人と語り合ってみるのが有効。
- 最初のステップで、ドメイン層を隔離するためにアプリケーション層を導入している。この1ページがキモ。
- 「ドメイン層」の議論を「機能」視点から隔離し、注目しなければならない情報はなんだっけと考える。
- ドメイン層にHTMLやSQLのコードが入ると汚染される。
- そうじゃなく、アプリケーション層を導入して、こーゆう機能を実現します、という「機能」の視点から隔離する。
- ドメイン層の視点でものを見に行こう。
- この発想の転換は最初すごく苦労した。
- 機能分割とか、そういう議論ではない。ドメイン層の議論は、機能の議論でもI/Fの議論でもない。
- チームがこれを当たり前にできるようになれば、相当変わる。
■ 第２部は基礎練習 （P.31）
- ここまでの第2部は、当たり前の内容。でも相当ハードルが高い。
- 私はサッカーが好きなので、スライドの例もサッカーで表現している。
- 練習の時からヘラヘラやってるのはムカつくんですよ。
- 練習の時から、試合で90分が経過したヘロヘロの時間まで、徹底的に確実にやること。
- 第2部わからなかったら先に第3部へいってもいいが、行ったり来たりすることを常に意識してほしい。
- 常に行ったり来たりすることで、より良いものができていくんだ。
ここから今日の本題
■第３部 より深い洞察に向かうリファクタリング （P.32～）
- 第1部がきっちり理解できて実践できていれば、第3部はどうでもいいかも。
- ここまでやると本当に役立つよ、というのをチームで共有できると、もっとわかってくる。
■ 主題：実際に役にたつモデルを探す （P.33）
- なぜこの章構成なのか、疑問があって、つかみどころがないところがある。
- 読み直したけど、ちょっとよくわからないな、というところがある。
■ 第３部 導入 （P.34～）
- ドメイン層の話。
- 設計技法の話とか技術用語とか出てきても、ぜんぶ疑って欲しい。
- エヴァンスが第3部で書こうとしてこととズレてるんじゃないか、と疑って欲しい。
■ 役に立つモデル （P.36）
- 主要な関心事は何？ それをわかりやすく表現するのはどういうこと？ というのが第3部。
- コードを相当しなやかにしておかないと、追随できなくなる。
■ コードのいやな臭い （P.38）
- いやな臭いのTOP4を書いている。
- コードが悪い、というのはエンジニアならすぐ分かるはずだが、それだけでなく、DDDとして一歩踏み込むこと。
- 例えば、ドメインの概念を見つけ出して、それをメソッドとして抽出するとか。
■ 「分割」ではなく「抽出」 （P.39）
- 「分割」ではなく「抽出」ということに気づくまで、すごく時間がかかった。
- ウォーターフォールなら、大きい物は分割しろ、となる。抽出が分割であると誤解してた。
- 大きいから分けるんじゃなくて、大きいなら、価値があるものが埋まってるから、それを取り出せ。
- 小さくするんじゃなくて、大事なものを抽出するんだ。
- 大きかったら分ければいいや、という考えでは、第3部は理解できない。
- 隠された大切なものを発見して、それを抜き出す、という考え方は非常に重要。
■ 深いモデル （P.40）
- ドメインの表面的な側面を捨て去る、とあるが、こーゆうものを捨て去れ、とパターンされてない。なので自分で意識してください。
- 1章で「トポロジーを外した」みたいな話。でも第3部で具体例が出てこない。
- でもモデリングのキモ。いかに捨て去るか。
- 第3部に書かれているパターンをソースコードにすべて適用しようとしても、得られるものはほとんどない。
- 深いモデルを探求するために焦点を絞っていくのが第3部。
- どこにフォーカスして第3部の内容を徹底的にやってみるかのフォーカス決めも第3部の重要なテーマ。
■ 深いモデル／しなやかな設計 （P.41）
- こっちよりあっちのほうが重要だよね、と一言いうのは簡単。でもコードを組み替えるのは難しい。
- なのでコードのしなやかさが必要。そうしないとコードがついてこなくなる。
■ 「モデル」の発見のプロセス （P.42）
- 「モデル」という言葉から、コードを書く前にする作業、という考えになるが、そうじゃない。
- モデルは開発プロセス中で発見していくんだ。
■ 8章 ブレークスルー （P.43）
- 「なんだ、そういうことか」、「目から鱗」といった経験。
- 問題意識を持ち続けていれば、「あ、こうすればいいのか」と気づくことができる。
- 凄い気づきが見つかったからハッピーだよね、じゃない。
- 凄い気づきを元に実験して実装しなおす判断は、インパクトが大きくてリスクになる。それをどうやってチームで制御しながら取り組むかがブレイクスルーのキモ。
■ シェアとシェアパイ （P.45）
- 協調融資によるリスク分散。そのドメインの話。
- 最初の設計は、一回ごとに貸出するシェアと、限度額のシェア、の両方が入り組んでいた。
- それが、「シェア」と「シェアパイ」にクラス分けることでブレークスルーが起こった。
■ 兆候と結末 （P.46）
- 兆候に気づいたのが、ブレークスルーに至る重要な感覚。
- おかしいな、という違和感を持ち続けて、常に疑うことが大事。
■ 第９章 暗黙的な概念を明示的にする （P.48）
- ドメイン駆動設計のキモ。探求したかったら概念を掘り出しに行きなさい。
- でも、現実は相当難しい。受託で納期もあるし無理な仕様変更も降ってくるなかでやるのは難しい。
- 概念を掘り出す5箇条に取り組むこと。
■ ２．ぎこちなさを精査する （P.52）
- ドメインの言葉で語ってみる。
- ifとかelseとかが自分の言葉から出てきたら、ドメインの言葉で語れていない証拠。
■ ３．矛盾について熟考する （P.53）
- 矛盾を感じたら、記憶にとどめておくこと。書き留めなくても良い。
- 後々、「あぁ、こーゆうことだったのか！」と気づけた時に、それは矛盾じゃなくなる。その時に学習成果になる。
- 「あー、そうなんだ」と、新しい理解として認識してしまうと、すんなり通りすぎて、学びとして残らない。
■ ４．文献を読む （P.54）
- 新人教育のテキストがあれば、ぜひ読んでください。そいう人向けに理解させようとする何かが得られる。
- 全部を自分で理解する必要はない。聞ける人を人脈として育てておく。自分の仕事も楽になる。
- 文献は、全部を精読しない。
- 目次や「はじめに」や第1章などで使われている全体図とか比較表、用語集をうまくピックアップして、それなりの感覚をつかむ。
■ ５．何度でも挑戦する （P.55）
- 回数を繰り返すことが「概念」を発見する基本。
■ 9章の補足 （P.57）
- 制約、プロセス、仕様、の３つ。これをオブジェクト指向で表現しようとすると大変。
■ ９章の補足：制約 （P.58）
- 概念を掘り出すためには、なんでもString型でいいじゃん、という考えではできない。
- 制約のなさに気持ち悪さを感じよう。
■ ９章の補足：「プロセス」 （P.59）
- 構造はオブジェクトとして表現できるが、プロセスはオブジェクト指向で表現しにくい。
- プロセスを表現する武器として、イベントストリームやリアクティブは非常に役立つ。
- ただ最近の流行りとして受け止めるのではなく、ドメインとして認識する。
■ ９章の補足：「仕様」 （P.60）
- オブジェクト指向では、やめたほうがいい・・・
■ 10章 しなやかな設計 （P.61）
- この章を10章として独立させてるのは、開発者がドメイン層に集中するためには、こーゆう設計にしておけば楽になるよ、実験がやりやすくなるよ、というメッセージ。
- メソッドの引数とかはValueオブジェクトにするのが望ましい。型として表現する。intとかだと、ドメインの関心事が表現できない。
- Valueオブジェクトは5章に出てくるが、10章の実践ネタとしても非常に有効。
■ その他のテクニック （p.64）
- 「制約」は表明を使ってコードとして表現すればソフトウェアが安定して、実験がやりやすくなる。
- コードにどんどん制約を埋め込む。
■ 攻める角度 （P.65）
- 「しなやかな設計」と「概念の掘り出し」は、同じ箇所に両方ないといけない。
■ 第１０章のまとめ （P.66）
- ポイントは２つ。
- １．技術者が「利用する人たちの関心事」に集中すための工夫
- ２．「しやなか」なほど、実験がやりやすい
- 10章は技術的なことなので、チームでまずここからやってもいいかも。
■ 第１１章 分析パターンを適用する （P.67）
- １１章は、語りたいことが山ほどある。
- 今日は語り尽くせないので、DDDAllianceの別イベントでやろうと思っている。
■ 第１２章 デザインパターンをモデルに関係づける （P.70）
- デザインパターンは技術的な観点で説明されている。なのでドメインに直接役立つものが多くない。 by エリック・エヴァンス
- ドメイン層の設計でデザインパターンを取り込むなら、ドメインの言葉でそのパターンがどういう意味を持つのか、チームで話し合って、意味があったら使おう、とするのがよい。
■ 第１３章 より深い洞察に向かうリファクタリング （P.71）
- ブレイクスルーの瞬間は大発見だし、すっきり感がある。だからといってすぐにコードを変更しよう、というのは危険。
■ リファクタリングの方向とタイミングを間違えないために （P.73）
- どこまでリファクタリングするんだ、いつやるんだ、という方向を間違えないように。
- ひとりでやるのでなく、選抜チームで取り組もう。
- 偏った方向に行くのを防ごう。
- ドメインエキスパートがピンとこないような「深いモデル」、というのはありえない。それはブレークスルーではない。
- ドメインエキスパートから最悪、ほとんど話をきけなくても、自分たちの考えたことがドメインエキスパートの考えから突拍子なことになってないか、だけは絶対にチェックしろ。
- ドメインエキスパートからのフィードバックは大切にしなさい。
- いつでも会話できる、ということよりも、そちらのほうが大事。
■ 第３部まとめ （P.75）
- 9章を地道にやり続けること。これがDDDのメッセージ。
- 第2部だけではダメで、第３部の内容を実践してこそ、ブレークスルーとか起こる。
★感想：
自分で本を読んでいたときは、今読んでる章に特化して視野が狭くなってしまいがちです。
でも、こーゆう風に全体を俯瞰して説明してもらえると、「あぁ、あの話は全体のここに位置していて、あの話と繋がるのか」といったような気付きが非常に多い。
自分の考えが整理されて一歩進む感じですね。これがまさしく、８章のブレークするーなのかも。
第３週のイベントも楽しみです。
増田さん、関係者の皆様、ありがとーございました。
- 関連記事
-
- 「DDD Alliance! 3週連続DDD 第3週」に参加しました
- 「DDD Alliance! 3週連続DDD 第2週」に参加しました
- 「XP祭り2015 “俺も！！”」に参加しました
