先日開催されたBPStudy#141〜DDD(Domain Driven Design)実践の現場に参加してお話を聞いてきました。
話を聞きながら、メモした大事そうなところを整理しながら共有できればと思います。
ドメイン駆動設計の正しい歩き方〜どこに焦点を合わせ、どう実践するか
増田さん（@masuda220 ）
ドメイン駆動設計でなぜつくるのか？(p.2〜p.3)
- 進化を続ける、変更が楽で安全なソフトウェアを手に入れるため
- 単に動くだけのソフトウェアにしないことに振り切っている
- 変化しなくてもいいソフトウェアだとフィットしないかも
ドメイン駆動設計とはなにか？（p.4〜p.6）
核心にある複雑さに立ち向かう（p.7〜p.10）
- Evansさんはソフトウェアの複雑さはたくさんあるけどなかでも複雑こそがビジネスの複雑さが根本原因と言っている
- Evansさんの考え方はここに立ち向かえばソフトウェアを整理できるという考え方
- ビジネスルールが特にソフトウェアの複雑さにダイレクトに効いてくる
核心にある複雑さを適切に扱う（p.11〜p.12）
- 核心とそれ以外の部分が明確になって整理できる
- 周辺（入出力）の複雑さが軽減される
- 全体が整理されていく
核心にある複雑さをどう扱うか 6つの問い（p.13〜14）
上記の3つだけやっていてもダメ…
チームの基本のこだわりポイントにこれらを置いて毎日続けているかがドメイン駆動設計をきちんとやっているかの指標。
→ 逆にこれを意識してきちんとできて居ればエースエンジニアがいなくても良いソフトウェアになっていく。
正しい道からはずれるとき（p.15〜p.17）
- ビジネスの活動から目をそらす（パフォーマンスチューニングに注力しすぎたり）
- 全体を均質にカバーしようとする（どこでも値オブジェクトやEntitynなどのドメイン駆動設計の戦術パターンを取り入れようとする）
→ コアのところだけを頑張る。メリハリをつける。コアじゃないところは手を抜く。
- ビジネスを表面的に捉えて理解した気になる
→ ビジネスの用語を意識していなかったところからだんだん使うようになってくるとやった感が出てくる。学習曲線の1つ山越えたとこ。その段階でビジネスのキャッチアップをできた気になり、ドメイン駆動設計を行っている気になっていると得るものが少ない
- 入出力の関心ごとをドメイン層に持ち込む
→ DBの都合はドメイン層に関係ない。普通はドメイン層のモデルを再生成しようと思ったら様々なテーブルから情報をかき集めてきて結合する必要があるはず。1つのテーブルの情報で済むならそれはコアドメインではない
- モデルと実装を切り離す
→ モデリングができるようになって楽しくなってきたときにやりがちなのがソフトウェアの実装に役に立たないことにもフォーカスしてしまう。
→ 実装のためのモデリングはどうしても細かい部分でスッキリしないことが多い
→ 綺麗すぎるのは危ないかも
- システム間を力づくで連携させる
→ 訳のわからないファイル読んだり、段々APIに項目追加されてきたり、APIで条件に応じて違うデータ返さなきゃいけなかったり…
→ システム間を繋げられてしまったらそこで進化が止まってしまう。常にもっと良い繋ぎ方があるんじゃないかと考えるべき。
ソフトウェアの核心にある複雑さに立ち向かう（p.17〜p.18）
- 青い項目（コアドメインに集中する、ビジネスを深く洞察する、システム間の秩序の改善を続ける）が肝
具体事例（p.19〜p.21）
DDD Allianceさんで開催しているドメイン駆動ワークショップのお題
- P.21のような但し書きがいっぱいの複雑なルール
複雑な料金計算ロジックをどうやってコードで表現するか（p.22〜p.24）
- ドメインロジックをまず隔離する
→ 画面の関心ごとと実際の計算ロジックを分離する
→ ビジネスルールだけで開発してそこだけでテストできるように開発させるという意味で、独立した存在として取り扱えるよう開発する
oO チームごと分けられるようにするくらいの意味合いかも
- 自然言語や数式、クラス図などを用いて構造、要素を整理する → コード書いてみる → うまくいかなかったらモデルにFBする → またコードを書いてみるという感じで行ったり来たりする
- 最初から良いモデルを作るのは無理。モデルとコードはズブズブの関係
コアドメインに集中する（p.25）
- 例えば、どう考えても幼児の寝具が料金計算の軸になってることはない
→ 主軸の取り方考える。（部屋のグレードなのかシーズンなのか）実験的にやってみてコードでうまく表せたらOK。
→ うまくいかなかったら軸の取り方を変えてまたやってみる。実験してやってみる方が早い
ビジネスを深く洞察する（p.26）
- 開発者が料金表にタイポがあった場合に指摘できるか。歯抜けが料金があったときに仕様を補完して提案できるか。
→ これが出来るほどビジネスを理解していると後から変更したいという要望があっても反映しやすくコミュニケーションロスも少なくなる。
→ そういうレベルで自分たちが業務を理解していないんじゃないかという意識を常にチームで持ち、互いに声をかけていく
システム間の秩序の改善を続ける（p.27）
- 外部の予約サービスではこの複雑なプランを表現できないのでどう簡単化して外部予約サービスで表示するかというのが課題になる。
→ 周辺のサービスなどの状況を俯瞰して把握することでコアのドメイン、サービスが締まってくる
ビジネスの活動を継続的に学ぶ（p.28）
上記の3項目（コアドメインに集中する、ビジネスを深く洞察する、システム間の秩序の改善を続ける）を行っていくためには必然的にビジネス学ぶことになる。
ドメイン駆動設計を現場に導入する（p.31〜p.32）
- 体験的に習得する
→ 大事だけど苦労するところ
- Evans本を読む
→ 特効薬じゃないけどじわじわ効いてくる。設計の質が変わってくる。時間のかけ方が変わってくる。ただし読みにくい→Evansの文章スタイルに立ち向かう
想定読者の要件をクリアする（p.33〜p.34）
→ 2003年くらいのオブジェクト指向の知識はむしろ捨て去った方が良いかも * オブジェクト指向設計の文献
→ 有名どころだと寧ろEvans本より鈍器で敷居高い
想定読者の要件をクリアする教材セット（p.35〜p.38）
→ 現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法の補足
Evans本をちゃんと読む（p.39〜p.49）
- 行ったり来たりするために紙の本を推奨
- あとから確認したり検索するために電子版もあると良い
- まずは28ページの抜粋版から読んでみる
→ どういうことを注力したいかということがわかる * IDDD本はEvans本の一部をピックアップして書いている本だというのを分かった上で読むのがオススメ
→ IDDD本で紹介されていない71のセクションにも宝物が埋まっている
Evansの文章スタイルになれる（p.50〜p.51）
- 本の中盤にある設計課題と考え方の説明を読んでから前の方にあるプロジェクトの経験談や具体例を読んだほうが理解が深まる
質問
- Q.ドメインエキスパートの説明力足りない場合どうしているか？
A.基本的にドメインエキスパートの説明が足りていることなんてない。具体例持っていくとよく話を引き出せる。わざと間違った具体例を持っていっても良い感じに話してくれる。スタートアップだとエキスパートいないのでみんなで考えるしかない。逆に自分が興味を持てない仕事はしない。
- Q.ドメインエキスパートが決定権を持っていない、アクセスできない場合どうする？
A.ドメイン駆動設計をやった手応えの1つで変更が楽だと仮の決定でコードを書くハードルが低くなる、抵抗がなくなる。確定したらそれに合わせるというのがやりやすくなる。
- Q.ビジネスルールが複雑になるのはなぜ？
A.ビジネスルールの複雑さに立ち向かうを参考にしてみると良いかも
感想
スライドだけでは説明しきれいない補足的な内容について口頭でお話されていて、そのお話の中にも勉強になる事柄が散りばめられていました。
技術的なパターンセットとしてではない、ドメイン駆動設計の心意気、考え方の部分というのを増田さんの言葉でお話していただいて、自分の実体験や本を読んだ知識としてしか知らなかった部分とリンクさせながら聞けて勉強になりました。
DDD Allianceさんで開催されていたドメイン駆動ワークショップに参加したときのことも思い出し、今回のお話を踏まえながら社内などでドメイン駆動設計を体験してもらう場として同じお題でワークショップを開催してみたいなというモチベーションにも繋がりました。
また、Evans本についてもお話いただいた要点や読み方を参考に再度読み直したいと思います。
大変貴重なお話ありがとうございました。
モデル駆動設計によるビジネスをソフトウェアに落とし込む1つのやり方
高崎さん（@ken_takasaki） speakerdeck.com
- 工業的にではなく工芸的につくるのがドメイン駆動設計なのでは
背景（p.8〜p.11）
ドメインの背景を知る
アクティアさんはJava×DDDの会社
なぜプロジェクトは炎上するのか（p.12〜p.15）
- 様々な理由があるけど技術的に複雑なものをシンプルに持っていくことができれば
モデリング（p.16〜p.19）
- ある物体や事象について簡略化した物を作ること
- モデリングを通じてビジネスとソフトウェアの乖離が見つかる。
- エンドユーザにコードを読んでといってもむりなので中間成果物がいる。それがモデルになるという取り組みを行っている。これによりモデルと実装が分離しない
ドメインの用語を理解する（p.20〜p.29）
→過去にあった2001年ごろ。UMLをつかってかいていく。
- 言語の歴史は抽象度が上がっている
- 廃れた
→ 何故か: 仕様や思想がふわっとしている。説明自体もふわっとしている
モデル駆動開発のいいところ（p.30〜p.41）
- ビジネス要件とプログラムの分離
- プログラムの均質化
- 自動生成による生産性の向上
当初のモデル駆動開発はグラフィカルだとぱっと見わかりやすいけど差分管理しんどい、動的振る舞いの表現難しい
→ 良い設計はなんだろうと考えドメイン駆動設計にたどり着いた
今はMarsという自動生成のためのプラットフォーム作っている
言葉を共有（p.42〜p.48）
通じない思い
DDDにはたくさんの言葉
- ドメインエキスパートと開発者の間で普通は乖離があり通訳するのに労力がかかる
→ ユビキタス言語で共有。言語に問題があれば代わりとなる言語を探してモデルを更新する
用語集を作るわけではない。その用語が浸透しきっている状態がユビキタス言語
ユビキタス言語やらかしたあるある（p.49〜p.53）
① 用語集を作る。メンテされない ② ドメインを集めて共有するために壁一面にユビキタス言語貼っていこうという試みを行う
→ 最初に自身が貼ってからだれも追従してくれず…
→ 結局浸透していないから
対話でユビキタス言語（p.55〜p.65）
対話をするためには
一般業務知識を学ぶ → 業種そのものを学ぶ → 顧客のドメインを学ぶのが大事
海図の販売管理の例
一般業務知識を学ぶ
→ 業種そのものを学ぶ。Webで調べる。実物をもらう。
業務を整理するときの手法
→ RDRA
区分を発見した実例
言語IDを用いてソートしたいなどの要件があった
→ 国とか商品とか様々な区分が含まれているように見えるが実際現場では言語IDとして取り扱っているので同じようにそう扱う
ユビキタス言語の選択をミスした実例
船主
→ よくよく考えたいったら顧客という用語が適切
→ かっこいい言語につられて失敗した例
ユビキタス言語は値オブジェクトになる
ユビキタス言語を表現することで概念や用語がソースになり顧客とエンジニアの間で話が通じやすくなった
貧血との戦い
抜けられない染み付いたやり方
ドメインモデルやらかしたあるある
→ テーブルから入るとそのデータ構造に引っ張られる
→ 結果ドメインモデル貧血症に
→ 貧血症にハマることは通る道なのでその後どうするか
ビジネスルールに集中する
→ ドメインだけでビジネスルールをまとめていく力をつける 見積伝票モデルの例）
値引きや為替というのを切り出してドメインに隔離
→ 隔離前のシステムにはなかったルールなのでお客さんにもFBを出来た
ビジネスルールをどこに持つか？
- 数量がビジネスルール知っているのは微妙
- 明細金額が数量と定価を知っているというように変えた
貧血とビジネスルールと日々格闘
感想
ユビキタス言語やドメインモデルの育て方などの話を現場の実体験をベースにお話しいただきました。
実際取り組んでみてどうだったというあたりや、こんな発見があった、こんな失敗をしたという生の話を聞けて大変勉強になりました。
特にユビキタス言語の深め方のあたりは前半の増田さんのお話を含め通じて今回の勉強会に参加して、次にフォーカスを当てて取り組んでいきたいという部分のお話だったのでかなり刺さりました。
お話の仕方自体も洗練されていて聞き入りました。
懇親会でも現場や実例の話を更にお話いただいて、非常に勉強になりました。
大変貴重なお話ありがとうございました。
最後に
今回の勉強会参加して、ドメイン駆動設計についての特に戦略的な話のところの理解がぐっと深まり、モチベーションも更に上げられるいい機会となりました。
お話いただいたお二方、企画、運営をしていただいた関係者に皆様、会場を提供していただいたPixiv様、大変貴重な機会をありがとうございました
