先日、レガシーをぶっつぶせ。現場でDDD！2ndに参加してきたのでどんな会だったかレポって行きたいと思います。
目次
自己紹介
どんな人間が参加したのかを簡潔に。
要約すると、サーバサイドでOOP（オブジェクト指向プログラミング）チョットワカルけど、DDD初心者。
・エリックエヴァンス本とか、実践DDD本は未読。
・業務ではDDDやってない。
・Webでユビキタス言語とか、ValueObjectとか、CQRSはなんとなく見た。
・コアドメインとかサブドメイン、境界づけられたコンテキストはよく分からない。
・JavaとPythonのサーバサイドエンジニアで、OOPチョットワカルくらい。
・デザインパターンは全部じゃないけど、ファクトリとかストラテジーみたいなよく使うやつはだいたいわかる。
第ゼロ部：趣旨説明
個人的には最高の導入部でした。
今まで参加したイベントの中でもひと際、モチベーションを高めてもらえた導入でした。
2025年のDX（2025年の崖）によって、年間12兆円の経済損失が発生する可能性がある。
という経済産業省のDXレポートを引用していました。
この損失を防ぐために、特に技術的負債に関してDDDが有効なのではないか？
仮に有効だとしても、それをどのように学ぶのか？
という回答として今回のほぼ全パートがアウトプット形式であるのだと理解し、納得。
個人的に日ごろから設計・アーキテクチャ・コミュニケーションの必要性と重要性を感じていました。
もちろん、モダンな技術とか、テクいことは開発者モチベーションとしても、技術的進化としても大事だとは思います。
ただ、それ以上にちゃんとした物を、ちゃんと作っていきたい。
といった、ある意味では開発者のエゴともいえる感情が常にありました。
この思いを少し和らげてもらい、今回のハンズオンに対して非常に高いモチベーションで挑めたと思います。
第一部：D:システム設計の中でのドメインモデルの役割を体感する(萩原)
萩原 利士成 さん(@hagifoo 株式会社レヴィ)によるハンズオン。
DDDというとプログラム設計とか、システム設計といったシステムに関連したイメージを持っていました。
しかしこのハンズオンでは、システムの外側であるワークフローの整理と、モデリングのための前準備に対してアプローチしていきます。
参加者5名＋運営1名の合計6名前後で1つのテーブルチームとなりました。
僕のテーブルでは、DDD経験がすでにある人や、僕含めてDDD未経験の人が半数ずつくらいの割合。
中には、20年もののシステムをDDDでリファクタしてますという猛者もいました。
[2019/12/29追記]
ハンズオンで使われたスライドはこちら
やったこと
できあがったものはこんな感じ。
第一部お疲れ様でした。
共通認識作る難しさを、図を作ることで合わせていくのが体感できて良かったです。あと、他のチームがどんなモデリングしたかめちゃくちゃ気になる。
#genbadeddd pic.twitter.com/xfFD0UHfSI
— Naoto (@Naoto_Oct) December 14, 2019
お題は、CS（カスタマーサポート）チームが顧客からの要望を管理するシステム。
流れとしては、まず、ワークフローの洗い出しを行います。
それが完成したら、作ったワークフローと照らし合わせながら関係図を作っていきます。
今回のハンズオンではスコープアウトされましたが、これをもとにモデリングを行ったり、クラスを設計していくことになります。
ワークフロー
ワークフローでは運営の人を仮想のドメインエキスパートとして設定して、情報を聞き出していきます。
機能を満たしているのか？とか、その人の業務の流れを教えてもらう事で抜け漏れないように見ていきます。
記載する際の抽象度はけっこう難しいですが、時系列順に並べるとよさそうでした。
主語はそれぞれのレーンにある名詞を元にしていきます。
情報整理が目的なので、あまりシステム的な厳密性は持たずに全体を俯瞰するイメージでした。
なるべく想定されるシチュエーションを聞いてみたり、ドメインエキスパートが使う言葉に合わせることでコミュニケーションとっていきます。
意識しないと、ハッピーパスを作りがちです。
なので、例外的なケースがあるかどうか確認するとよさそうでした。
例えば、CSチームが顧客要望をリジェクトする際のパスとかですね。
関係図
作ったワークフローをもとに、各登場人物（主に名詞にあたるところ）をいったん列挙します。
列挙した名詞にたいして、矢印線とかUMLでいう1-*のような数字の関わりを書いていきます。
システムを目線にすると、ほぼすべての名詞に関係線が伸びるので、その辺はシステムが主語となる線は書かない。など要調整ですかね。
整合性チェック
一通り線を結び終わったら、ワークフローの時系列をもって、整合性チェックします。
関係図にある名詞が、ワークフローにない場合はワークフローの漏れ。
逆に、ワークフローにあるのおに関係図になければ、関係図の漏れ。
といった具合にチェックしていきます。
ここで面白いのは、ワークフローで抽出したつもりになって、関係図からまだ見ぬ発見があることです。
例えば、ユーザが持つプランによって、ワークフローが変化したりする場合があると、ワークフローの抽出不足となりえます。
休憩中の交流
休憩時間と第一部終わった後の同じチームの人との立ち話。
スライドで伝わらない細かい話が得られたり、ざっくばらんにお話できるのでオンサイトならではのこういう雰囲気は結構好きです。
Q.新規事業のようなドメインエキスパート不在の場合はどうするか？
A.マネタイズについて考える必要もあるので、経営層（PMとかPOも含む？）も絡んだうえで作っていくと、必要なワークフローが見つかるかもしれない。
Q.チーム全員がこの図をつくる必要はあるのか？
A.個人的には時間があれば参加した方がよいと感じます。ただし、チームによって時間配分が難しい場合はチームリーダーが持ち帰って展開する。などはあってもよい策です。
全体通して
コミュニケーションの可視化手法として有効だと感じました。
いわゆる設計書の一部となりえるようなポジションだと感じます。
共通語を作ったり、単語の意図を説明するコストを和らげたり、システム改修の困難さをステークホルダーやドメインエキスパートに理解してもらう上で、こういった図があると説明しやすいと感じます。
反面、どうやってこれらの図をメンテしていくのか？といった課題や、どのタイミングで作るのか？
といった点は各チームやプロジェクトに合わせていく必要がありそうです。
新しいメンバーが加わったときに一度やりなおす。というのは有効だろうということでした。
実際に手を動かしてみないと分からない気づきもあるので、そこに関しては同意できます。
ハンズオン中、弓山 彬さん(@akiray03 株式会社レヴィ)と、仮想ドメインエキスパートを担当して頂いたLAPRASの小屋さんには大変お世話になりました。
本当にありがとうございました。
第二部：E:ドメインモデリングハンズオン(松岡)
松岡 幸一郎 さん(@little_hand_s 株式会社ビズリーチ)によるハンズオン。
前半は座学というか、今日どう進めてどこまでやるか？という導入のお話。
残りの50分で8名1チーム（合計3チーム）に別れてモデリング。という流れ。
やったこと
こんな感じでモデリングしました。
お題はフリーで、各チームが決めるスタイル。
難しすぎず、簡単すぎないのをチームで決めていきました。
結果、婚活をモデリングすることに。
導入部分
良いモデルってどういうことでしょう？
いざ言われると、結構みんな困惑していてちょっと安心しました。
その時、DDD未経験なりに考えてみた結果。
モデルは「同じモデルを見た複数の人が、同じ印象を受けられるように形式化したもの。つまりは言語化」
良いモデルは「良いモデルを用いると、複数人がコミュニケーションを容易にとれるもの。つまりは常識」
みたいに考えました。
一応、その場の回答ではEricEvansの定義から引用され、
良いモデルは、課題を解決できるもの。
悪いモデルは、課題を解決できないもの」
ということでした。
今回は時間の関係上、集約については今回はスコープアウト。
ただし、モデリングの際に集約もまとめて行えると、そのまま機能開発できるのでGoodとのこと。
モデリング対象を決める
誰か1人がドメインエキスパートになるので、まずはチーム全員が得意とするドメインを列挙していくことに。
配車
魚
ランニング
動画配信
歯科
などなど・・・
しかし、途中で「婚活」という誰がドメインエキスパートするのかすごく悩ましい対象が浮上。
もろもろあった後の多数決の結果、「婚活」に決定。
もはやドメインエキスパートとは？という感じの雰囲気でモデリングしていきます。
ユースケース
まずはユースケースを決定。
退会とか管理系は煩雑になりそうなので、スコープアウト。
多少イメージを合わせる必要があったけど、15分の時間をまるまる使ってなんとか仕上げ。
モデリング
ここでモメにモメる。
というのも、やはりドメインエキスパート不在なのが大きくて、認識のすり合わせが結構時間かかりました。
イメージが8人揃うまで、あーでもないこーでもない。というカオス感がありました。
現場でも稀に同じようなシチュエーションになりますね。
ただし、既に関係構築できているチームメンバーなら大丈夫でも、今回はほぼ全員初対面なので若干のピリつきとイラだちを感じました。
特に気を付けたいのは、「他人の意見の最中は遮らない」ことと、「強い言葉は避ける」の二点でした。
全員大人なので、折れるところは折れるけど、内心「なんだかなぁ」という感情は持ってしまうんじゃないかなー。
最初の数分でもいいから、自己紹介なりこの辺に対するジャブ打っておいた方が良かったかもしれません。
とはいえ、全体通して形にはなったのでヨシ。
他チームのテーマ「ブログ」では、コメントの集約をきっちり切ってて面白いと思いました。
クロージングセッション
Slidoで上がった話題を軸に、8つのグループにわかれてトークセッション。
ナビゲーターは再びの弓山 彬さん(@akiray03 株式会社レヴィ)。
トークテーマはSlidoから引っ張ってきたやつ。
設計が大切だというところはわかってもらえても、なぜDDDなのかという部分の話が難しいです。それがベストなの？と聞かれたときにどう返すとよいものでしょうか。
面白かったのは、「実装だけでコミュニケーション取れればいいのに」という思想に対して、「そこを翻訳する成果物として設計書がある」という対立関係が存在すること。
もはや文化的な問題もあるので一概にはまとめきれないけど、僕個人としては「ただ慣習的に設計書を作るだけ」ならやりたくないな。という思い。
要は目的があれば作ろうよ派。
あと、「ベストを求めてる時点で負け」みたいな意見は妙に納得感あって面白かった。
話の最中に気になったんですが、そもそも人類はなぜ設計書とかいう代物を発明したのか。
想像だけど、プログラムの翻訳物として必要になった。とかそういう事情だと思うので、翻訳する対象によって必要性と対象物は変わるんだろうと思う。
例えば、個人でやっていれば翻訳する必要はないので設計書は不要かもしれない。
チームで働くにしても、チームのレベル感とかどこまで疎通できているかで必要性はたぶん変わってくるし、アウトプットされるべきものも変わってくる。
いわゆるお客さんとかステークホルダー向けだと、さらに翻訳した形にする必要があるかもしれない。
このへんのアクセルとブレーキを上手にできないと、結局無駄に作ったり、不足してカオスになったりするんだろう。
全体通じてのまとめ
最近インプットばっかりだったので、アウトプット中心でとても面白かったし、興奮しました。
参加してみて、「結局コミュニケーションだよな。」みたいな結論になってしまった。
たぶんこれは、参加したトピックがほぼ全て戦略的設計に寄った結果なのだと思う。
たぶんDDD的には、色々そうじゃないよ！みたいなのがある気がするので、特に戦術的設計はもう少し勉強してからアウトプットしたい所存。
今回のような考える機会と、DDDの初めの一歩を与えてもらって非常に感謝。
ありがとうございました！
参考リンクと参加者レポート
レガシーをぶっつぶせ。現場でDDD！2nd 「インプット＜アウトプット！」に参加してきました@suman_yarn
[2019/12/29追記]
レヴィさんのブログにて報告会の様子などがアップされましたー