connpass
http://ddd-alliance.connpass.com/event/18962/
Togetter
http://togetter.com/li/876882
先々週行われた第１週と、先週行われた第２週も参加しました。そんとき書いたブログはこちら。
今回はその第３週（最終回）なのでした。
会場が銀座の歌舞伎座タワーにあるドワンゴさんということで、隣りにある歌舞伎座の写真を１枚パシャリ。
第3週（14章～17章）戦略的に取り組む
以下、口頭説明部分を中心に当日取ったメモ。
---
■ 3社での取り組みの事例 （P.5）
(1) HRソリューションズ
- 人事採用のドメイン。仕事があって求人があって応募する、というドメインは単純。
- 採用雇用は経営戦略に関わる。
- あと採用担当者の独自性が強い。こーやりたい、という思いがストレートに出る。
- 社長がエネルギッシュで営業しまくるので、システムが追いつかないという状態だった。
(2) SBヒューマンキャピタル
- こちらも人材系サービス。
- 人材系サービスは、応募者情報を流通出来ている業界。
- 似たようなサービスが違うモデルで実装されてるサービスをどう連携させるか、とても勉強になる。
(3) ビッグローブ
- 契約、課金、キャリア連携とか業務的にヘビーなシステムに取り組んでいる。
- レガシーが今のままではどうにもいかないので、将来に向けて自分たちの戦略で取り組んでいる。
■ 取り組みの現実 （P.9）
(1) HRソリューションズ
- 経営のスピードがシステムより早いので、スピード重視。
(2) SBヒューマンキャピタル
- 若手メイン。短期的問題で忙殺されがち。現場レベルでの戦略的な意識向上から始めている
(3) ビッグローブ
- 壮大な取り組みなので、結果を出すまでに相当時間かかるだろうけど、一歩一歩進めている。
■ 戦略的に取り組む （P.10）
- 「すぐには見えない効果」 ・・・ 予算取りでうまく説明できないのはそうとう障害。
- 「それでも取り組む動機」 ・・・ これはシステム屋の本能。いいものを作りたい。
- 「一歩一歩進む」 ・・・ 一歩一歩を同じ方向に向かわせるか。
■ 誰がやるのか （P.10）
- これは第4部の大きなテーマ。
- アーキテクチャチームとかPMOとかがマスタープラン作る、という思想とは真逆。
- そうじゃなく、現場の人が視野を持って、コードに反映する。
- コードを書く人が戦略的に取り組むのが一番効果的、というのがDDDの思想。ここがポイント。
- 綺麗な図とかマスタープランじゃない。大事なのは「言葉」なんです。
- 戦略をコードに反映してはじめて効果が出るんだ。ドキュメントにいくら書いたってダメ。
■ 戦略的に取り組む場合こそ基本が大切 （P.12）
- これが一番いいたいこと。戦略的だからといって基本から離れたらダメ。
- 第１部～第３部の内容を基にして第４部に取り組む。DDD本もそういうストーリーになってるし、やっぱりそうなんだな。
- 第４部だけやっても意味はない。第１部～第３部とXPとOOを抑えながら長い時間取り組むのがDDDの戦略的設計。
■ 戦略的 （P.14）
- 選抜された人がやるんじゃなくて、多くの関係者で。その一番の道具が「言葉」。
- 時間をかけて、お客様のシステムを良くしていく機会はあまりないが、そうしていければ幸せ。
■ オブジェクト指向と「変更容易性」 （P.16）
- オブジェクト指向は変更容易性を相当重視している。
- 「抽象データ型／段階的抽象化」、モジュール化はこれまでもずっと言われてた。
- 「メッセージング」はオブジェクト指向に独自かも。モジュールに分離したとき、どういうふうにしておくと変更やりやすくなるんだっけ、と考える際、アラン・ケイはメッセージングを重視している。
- 最近はリアクティブプログラミングとかが登場して、この辺は少し変わってきた。
- 手続き型だろうが関数型だろうが、ドメイン層を人間に近い考え方で部品化して人間の関心事をコード化した場合、それほど変わらないだろうな、と思う。
■ 抽象データ型／段階的な抽象化 コードを人間の発想に近づける （P.17）
- 自分で型を宣言することで、ドメインオブジェクトの型でプログラミングしていこう。
■ 「モジュール化」と「メッセージング」 （P.18）
- 独立性の高い部品同士を「メッセージ」で繋ぐことで、構造の組み換えとかがやりやすくなる。
- 完全同期ではなく、非同期でメッセージをやりとりする。
■ ソフトウェアの開発スタイル （P.20）
- 変更のコストとリスクをどう下げるか。これまでは「変更」との戦いの歴史。どう安全に変更するか。
(1) 変更を管理する （予測型）
- もともとは、「変更は管理する」という予測型の思想だった。
- きちんと最初に決めて、ゴールに行けるのがいい。でもそれは無理だから、変更を管理していきましょう。
(2) 変更を受入れる （反復・漸進型）
- 1990年代くらいから「変更を受け入れよう」というRUPに代表されるような考え方が出てきた。
- まず作ってみて、それで目標を設定しなおす。
(3) 変化を目指す （適応型）
- XPはもっと違うことを言っている。変化に対応するよりも、変更を目指そう。
- ソフトウェアを作るってことは、変更していくこと。変化が常に頭の中心課題であるべきという哲学。
---
- 「予測型→反復・漸進型→適応型」という推移は、発展というより、それぞれ違う世界のような気がする。
■ 変化を目指す開発チーム （P.21）
- 変化を目指す開発チームには何が起きるか。
(1) コミュニケーション
- 変化を目指していこうよ、となると、「何が変わった？」、「今度は何を変える？」とコミュニケーションするようになる。
(2)シンプリシティ
- 単純な方が変化させやすい。できるだけシンプルに保つことで次々変化させる。
(3) フィードバック
- 変化するためには、フィードバックに基づき次の道を探っていく。
(4) 勇気
- 行動する勇気というだけではない。
- 変化の必要性に気がついているんだけど、今はそのタイミングではない、とぐっと思いとどまるような忍耐力、耐える力も「勇気」。
(5) リスペクト
- 相手に感心を持つことなんだ。相手のことに興味を持たないのは、リスペクトではない。
■ ３つの原則を戦略的に （P.27）
- 第１章の「ドメインの知識を噛み砕く」というのを、長期的に大勢で、広い範囲でやること。
- 戦略的であっても、抽象論だけでなく、コードで表現しないとダメ。これが第４部のキーポイント。
- 規模が小さければ「削る力」はあまりいらないかも。
- でも戦略的に長期的にやるときには、削る力、実験する勇気は、高いレベルが求められる。
- モデルと実装を結びつけること。戦略もコードに落とし込んで、変えていくんだ。
■ 第２部を拾い範囲で長期的に （P.31）
- 「システム間連携」となると、システム的な話になりがち。
- でもそうじゃなくて、各システムのドメイン層の中核をどうマッピングしていくかが重要。
- それは「システムインタフェース」間の話ではない。
■ 第３部を戦略的に実践する （P.32）
- 相当焦点を絞らないと、コスパが悪い。
- 「深いモデルの探求」と「しなやかな設計」は、焦点絞って、そこでやるべき。
- その波及効果があれば、他がボロボロ、ということにはならない。
- そういうスキルがあれば、絞った箇所以外も良くなる。どんどん波及していき、ドメイン層全体が綺麗になり、ドメイン層を使う他３層も軸がはっきりする。
- ドメイン層の中核を的確に捉えるチームが活動することで、どんどん周りに波及していく。
- その波及を、世代やチームを超えて如何に伝えていくか。
- 第１部～第３部のことを地道に一歩ずつコードに落としていく。
ここまでが主に前回の復習。第４部からがこの日の本題。
■第4部 戦略的な設計 （P.36）
- 14章以降は、経験あるエンジニアは、あーそうだよね、と思い当たる内容が多いのではないか。
- そいうことを言語化したい、並べてみた、という意味で価値が高い。現場で経験してきたことが言葉になっている。
■ 14章 モデルの整合性を維持する （P.38）
- ７つの見出しのうち、赤字の４つを中心に説明する。
■ 境界づけられたコンテキスト - 大きな部品を特定する （P.40）
- キーワードはモデル。どういうモデルを元にアプリが組み立てられているのか。境界はどこで切れるか。
- 開発チームが分かれているのにモデルは１つを共有している、というのはありえないので、開発チームが「境界づけられたコンテキスト」の候補となる。
- １つのチーム＝１モデル、は候補なのであって、必ずそうあるべき、というわけではない。
- １つのモデルが追求できる範囲がコンテキスト。
- １つの範囲ではあるけど、モデルはどんどん登場していく。人が増えたり時間が経過したり。同じ人でも違うモデルになったり。
- そのリスクをキャッチしながら、徹底的に１つのモデルにしようね、と努力をする。
- そうすることで、それぞれのモデルは明確になるから、マッピングできるようになる。
- 「境界付けられたコンテキスト」内で純度を保とう。
■ ひとつのコンテキスト内で継続的な統合をする （P.41）
- 「概念」は、別々の人の頭の中でばらばらに進化をはじめることに、いつも注意する。
- 人が集まって仕事をしている以上、ある日、みんなが共通認識をもった、というのは素晴らしいが、それがずっと続くかというと違う。放っておくと徐々にバラバラになる。それを１個に保つかが重要。
- ここで言う「継続的な統合」は、コードを毎日自動でビルドしてCIで統合している、というのとは違う。
- 「概念」は言葉にできないと意味がない。そうじゃないと、みんなが同じ概念を共有していることにはならない。
- 相手が何を考えているかに感心を持って、ドメインの一貫性を維持する。
- 単独のコンテキストの純度を如何に保つがが前提。それが前提で連携がある。
■ コンテキストマップ （P.42）
- そんなに綺麗に境界の線が引けるわけではないので、この図は境界をぼかしている。
- ドメイン層の中の重要な部分に絞ったモデルについてマッピングを考えるのがコンテキストマップ。
- ビッグローブで３０人のリーダーが集まってコンテキストマップを作った。すごい興奮する出来事だった。みんなの頭に埋もれていたものが明らかになってきた。季節代わりくらいのタイミングでもう一度やるのが効果あるんじゃないか。
- 理想論じゃなくて、現実を関係者で共有するということが大事。
■ コンテキスト間の関係 （P.43）
- 最近出た７０ページくらいのDDD資料（Domain-Driven Design Reference）にも出てくる。
- これはエヴァンスの書籍の図。
- 横軸が「チームのコミュニケーションの意欲と能力」。それが高くなることが前提で、縦軸の「関連するシステムに対する制御」は、それによってどのくらいでコントロールできるようになるか、自由にできるようになるか。
- 横軸も縦軸も両方共０なら、「別々の道」を進むしかない。
■ 第１４章の要点 （P.44）
- 前述したビッグローブさんがコンテキストマップを書いてて、美しいと思った。人間臭い。
- でも、妥協しながらここに辿り着いて、それが事業を支えている。
■ 密接な関係を実現する （P.45）
- 「共同経営」は、相手の経営にも相当口を出すし、相手の設計にも口を出す。
- それが枠組みとして保証されているのが「共同経営」。
- 明らかに共通部分があるので互いに共通開発しましょう、というのが「共有カーネル」。
- 本当に取り組むべきかの意思決定を、開発チームが、つまりコードをいじる人たちが考えて戦略としていく。
■ 明確な関係を打ち立てる （P.46）
- １チームになるのはなかなかできない現実的な解として、「顧客／供給者のチーム」がある。
- 「顧客／供給者のチーム」、」「公開ホストサービス」、「公表された言語」は、誰かのものに誰かが合わせる、という点で共通。
- 「公開ホストサービス」を作る側と使う側でコミュニケーションできるなら、とってもいい解になる。
- そうじゃなく、作る側が使う側に一方的に「使え」というのはダメ。
- 「公表された言語」の例としては、ERPで人事データを交換するのに使う「HRXML」というものが公開されている。
- そーゆうものを使って統合していくのが１つの解。でもあまり使われていない。汎用的になりすぎてて、使いにくい。
- 総論は合意できても、具体案までは合意できないので、具体案は自分たちでビジネスにしたほうが上手くいくので、人材系ではあまり使われてない。でもそーゆうXMLの標準とかがあれば、勉強すれば役に立つ。
■ 独立した別のチーム （P.47）
(1) 別々の道
- デフォルトは、開発チームは別々。自分たちのことでめいいっぱい。
- でもチームが分かれてたら、別チームに関与するの難しい。
(2) 順応者
- 別のチームが作ったものをベースにしてしまうと、連携が楽だよね。
- でもチーム同士が対等じゃなくて、そっちで決めてください、的な思考停止モデルになりがち。
- でも現実はけっこう多い。
(3) 腐敗防止層
- お互いがどーゆうモデルを持ってるかの知識を持ち合うが、調整ごとを一切せずに、間をコンバートしてしまえ。
- そうすると、自分たちの責任でできるようになる。
- 別のチームで行動してしまおう、というのが思想の根底にある。
■ コンテキスト間の関係の意思決定 （P.48）
- 「意思決定」とは、どうコードにどう反映するか、ということ。
■ 戦略を選択する時の考えどころ （P.49）
- ３９１～３９８ページは、ドメイン駆動設計らしい現場の体験談が書かれている。
- 厳しい現実に対して、どう実践的に判断したかの話が書かれているので、この８ページは徹底的に熟読してほしい。
- 実際的なエヴァンスの体験談が濃厚に書かれている。
- コードに影響しそうな人たちに共有しにいくのが、コンテキストマップをひろげていくことになる。
■ 変換（関係を変えていく） （P.50）
- 今の関係はこうなんだけど、こーゆう関係にもっていきたいよね、という話。
- 実践的な話が書いてあるので熟読してほしい。コンテキストマップを広げていくために共有してほしい。
- 現場の体験談。
■ 第１４章まとめ （P.51）
- 「意思決定」を必ず「コード」で表現すること。
■第１５章 蒸留 （P.52）
- コアドメイン、ドメインビジョン声明文、協調されたコア、凝集されたメカニズム、が段階的な話になっているので、そーゆうストーリーとして今日は話します。
■選択と集中 コアドメイン （P.54）
- 選択と集中。中核中の中核を見極める。見つけに行くことですごく得るものがある。
- 規模が大きくなると、一発で見つかるわけがない。
- そのためには要約力を磨くとか、実験してフィードバックを得ながらコアドメインを識別していく。
- 商売をやって稼ぎに行ける場所には複雑なドメインモデルがある。
■ 中核の探し方 （p.56）
- DDD本に具体的に書いてある。
- 顧客クラスから住所を抽出するのと同じ考え方。
■ かたまりを「抽出」する （P.57）
(1) 汎用サブドメイン
- いわゆる、注文とか、認証とか、アプリによくでてくる概念で切り分けていこう。
- その段階で中核はどこかわからない。でも、ざくっとその単位で分けてしまうのが核を見つけに行く準備作業。
(2) 凝集されたメカニズム
- コードが複雑になるところを隠蔽すると、そこを取り出すとシンプルになる。
- 塊を分けることで、じゃあコアはなんだんだ、とチームで議論する準備ができる。
■ 「かたまり」の「意図」を明確に （P.58）
- 塊間の依存関係が重要。
- 関係を言葉として表現することで、意図が明確になっていく。
■ 「コアドメイン」の具体化 ４つの段階 （P.59）
- 「コアドメイン」の具体化には４つの段階がある。
- ドメインビジョン声明文
- 強調されたコア
- 隔離されたコア
- 抽象化されたコア
■ ドメインビジョン声明文 （P.60）
- ドメインの中心的な関心事を言葉を使って書く。これは費用対効果が高い。
- ワークショップでもやる。チームによい影響を与える。
- 語尾をあいまいにしない。「～なんだけど。」とかはダメ。癌になる。
- ふつうの会話としては形式がおかしいくらいにきっちり正しく表現するようにしてください。
- 文を切らない。
- 「あれ」、「これ」、「それ」を使わない。ラフスケッチを書いた瞬間、あれがこうなって、と言い出すが、アンチパターン。
- カタカナ言葉はみんなの理解がばらつくので、同音異義語が少ない大和言葉にまでする。
■ 協調されたコア （P.61）
- 重要な要素をマーキングしにいく。マーカーで色をつける。ゲーム感覚でやるだけでも相当価値がある。
- 何が重要か、何を捨てるべきか、という議論をする。
- 絵にしてみて、マーキングできたよね、で終わっちゃダメ。大切なのは、言葉で表現してみること。
■ 隔離されたコア （P.62）
- 重要と思われたものを１つのパッケージにまとめてみる。
- コードとして重要なものが明確になってくる。レベルの高い蒸留。
■ 抽象化されたコア （P.63）
- 抽象化の最終形。
- これができた！という経験はあんまりない。部分的には経験してる。
■ 第１6章大規模な構造 （P.65）
- テーマは、「森を見る力」。
■ 「森」を少しずつ成長させていく （P.68）
- バサッと構造を綺麗にするのではなく、徐々に改善していく。そうすると全体が少しづつ成長していく。
- 機械的な秩序ではなく、有機的な秩序。これはアレグザンサーの本にも出てくる。
■ メタファー
- 個人的に好きじゃない。カタカナ用語だし。イメージが沸かない。
■ 責務のレイヤ （P.70）
- 候補は、一番下の「潜在能力」から一番上の「意思決定」。
- 複雑になったら５層に分けろ！ではなく、考えていくと５層に分かれる、という話。最初は２層くらいに分けるところから。
- 一方向のオブジェクト構造にするとやりにくいことがある。でもそうする実験をすることで、より良い設計の気づきが得られたりする。
- うまくいかない、というところがブレークスルーの手がかりになる。
■ 知識レベル （P.72）
- アナリシスパターンにも出てくる。
■ 第１７章 戦略をまとめ上げる （P.76）
- 戦略設計上の意思決定に欠かせない箇条書き６条は読み直してください。
★感想：
３週に渡って徹底的にDDD本の話を聞けて、すごく頭の中が整理された感じだ。
ここまで徹底的にDDDを語り尽くす勉強会というのは初ではなかろうか。
増田さんは講演の中で、自分の会社の宣伝とかに時間を割くことは一切されなかった。
３週連続、合計６時間、休憩無し。その時間をフルに使って、聴講者が求めるDDDについて語り尽くしてくださった。
これは凄いことだと思うのです。
完全に損得勘定なんか抜きで、数百ページのスライドを作成して、参加者の期待に応じてくださったのだから。
しかも無料。ホント感謝です。
今回のDDD３週連続の内容を噛み砕くためにも、是非もう一度、書籍を読み直したいと思うのでした。
あ、それもいいけど、実践的な新しい本も出たことだし、そっちの読書会とかあると更に嬉しいな～
誰か主催してくれないかな～ （チラッ
実践ドメイン駆動設計 (Object Oriented Selection)
posted with amazlet at 15.09.22
ヴァーン・ヴァーノン
翔泳社
売り上げランキング: 38,983
翔泳社
売り上げランキング: 38,983
増田さん、関係者の皆様、ありがとーございました。
