はじめに
BIGLOBEの西です。
まずは、12/14(土)のレガシーをぶっつぶせ。現場でDDD！2ndに、
ご参加いただいた皆様、ありがとうございました
今日はイベントの中で開催した、
1-B:モデル・コードの変更が互いにどう表現されるか体験するためのハンズオン
のセッションについて解説と狙いを書いてみました。
この記事を読む前に、ぜひハンズオンを実践してみてください。 記事の解説がより理解できるようになります。
なぜハンズオンなのか？
有名な格言があります。
「百聞は一見にしかず」「百見は一考にしかず」「百考は一行にしかず」
要するに、1ハンズオンは100万回(100聞 × 100見 × 100考)聞くのと同じ効果があります (単なる誇張です。最近はDDDに関する記事も増えてきました。
基本的な知識や考え方を得る手段は多くなってきたと感じています。
それと同時に、
「どうやって導入・実践するのかが分からない」
という悩みも増えて来ていると感じています。- そのハードルを下げるために、
「とりあえずやってみた」
を経験してもらいたいと思いハンズオンを用意しました。
ハンズオンの概要
ターゲット層
- DDDを知っているけどやった事はない or やってみたい。
- コードを書いている人。
- チームで開発をしている人。
体験できる事
- サービス仕様からドメインモデルを作成する。
- ドメインモデルからソースコードを作成する。
- ドメインモデルとソースコードの関係性がちょっと分かる。
体験できない事
- Entity : 状態の管理などライフサイクルの考え方。
- Aggregates : トランザクションなど整合性の考え方。
- Repository : 情報が永続化/コンテキスト外へ依存してる場合の考え方。
DDDモデリングハンズオンの資料
説明用資料
www.slideshare.net
ソースコード
DDDモデリングハンズオンの流れ
- 仕様の把握
- ドメインモデルの作成
- ソースコードの作成 (テストが通る事を目標にがんばる)
- ドメインモデルへのフィードバック
1. 仕様の把握
- まずは何を作るのか仕様が分からなければ何も始まりません。
- スライドでは説明のため図を用いていますが、可能な限り先入観を与えないように配慮しています。
仕様はマトリクス表など用いた説明の方が伝わりやすいですが、先入観も与えやすいです。
今回のセッションでも、説明後はテキストベースの仕様を紙で配布して仕様を把握してもらうようにしています。
(仕様＝ソースコードのreadme.md)
2. ドメインモデルの作成
- 名詞と動詞を探して、ValueObjectの候補を考えてみましょう。
- ユースケースを当てはめてみて、モデル上で処理や依存が正しそうか考えてみましょう。
- 当日は名詞や動詞を付箋に書いて、シートに貼りながらモデルを作りました。
(みんなでドメインモデルを見る & 誰でも編集ができる状態を作るため) - サラッと書いてますが、この作業を始めることが最もハードルが高いです。
(しかも、当日の参加者は初めて会った人たちと一緒にやるというハードルもありました) - ドメインモデルを作ったことがないとゴールが見えないので、何のために名詞を探すのか見えてきません。
ただ、ここでも説明より体験です。
思いつく限りの名詞と動詞を集めてみましょう。
あと、採用されなかった、名詞、動詞も残しておくと後で議論に使えます。 - このフェーズは一番議論が発散しやすいです。
「まずは〜のドメインだけを考えてみませんか？」
など、議論をファシリテートする人を置いて議論のターゲットを誘導した方がスムーズに進みます。
3. ソースコードの作成
- ドメインモデルを忠実にソースコードへ落とし込み、まずはテストコードが通る事を目標にします。
この後の議論でモデルとコードを変更する可能性が高いため、
テストコードが動く状態(=動作が変わらない事が保証された状態)で、
リファクタリングをできるようにしたいためにです。 - メソッドの引数、戻り値にプリミティブ型(String, int, long... etc)を使っていないか意識的に探して下さい。
使っていたら、その値は何のドメインなのかを考えて、ValueObjectにできないか検討してみましょう。
4. ドメインモデルへのフィードバック
- まずは、新しく見つかったドメインやメソッドがあればドメインモデルへ反映しましょう。
- その上でドメインモデルが適切であるのかを議論してみて下さい。
- 議論が行き詰まった場合、ビジネス的にありえそうな仕様変更を考えて、モデルとコードにどう影響が出るのか考えてみると良いです。
変更するクラスやメソッドが少なければ、それはいいモデルです。
多くの変更が必要になるのであれば、モデルに良くない点があるのかもしれません。 - この先の議論はゴールはありませんので、時間は区切ったほうが良いです。
社内でお試しで開催した時は議論が発散して2時間以上かかりました。
このハンズオンで一番体験してもらいたかったこと
ドメインモデル ⇔ ソースコードを往復する意味を知ってもらう
ドメインモデルからソースコードへ落とし込む事で、今まで見えていなかったドメインが見つかったり、理解が一気に進みます。
この事実が一番伝えたかった事で、 それは、理屈より体験する方がより実感できると思いハンズオンという形式にしました。なぜ、モデルをソースへ落とし込むと理解が進む？
ドメインモデルとは？
ドメインモデルはソースコードに比べると抽象的なモノです。
仕様からドメインモデルを作成する時に、細部はあいまいなままでも作る事ができます。
(モデルではコンパイルエラーは発生しません。)
しかし、初めはドメインへの理解が浅いため、細部は分かりません。
つまり考えても無駄です。前に進みましょう。ソースコードとは？
ソースコードは厳格であいまいさや間違えを許してくれません。
あいまい=即コンパイルエラーです。
そのため、ドメインモデルの段階で残っていたあいまいさを、具体的に解消しなければいけません (例: 引数に渡すクラスを明確にする、料金を合計するためには新しいクラスが必要なった、など)。 依存関係も矛盾があれば気づく事ができます。
これらは、ドメインへの理解不足が表面化したために発生しています。
そして、その問題点を解決する事でドメインへの理解が深まります。そして、再びドメインモデルへ
ソースコードを作成したら、その知識を持ってドメインモデルを見直してみましょう。
その時のあなたは、昔のあなたよりドメインを理解しています。
強くてニューゲームです。
初めにドメインモデルを作成した時には気づかなかった新しい観点が見つかり、ドメインが磨かれます。
モデルという抽象とコードという具象を往復する事で、頭の中が整理されてドメインの理解が深まっていく。
これが、DDDモデリングハンズオンで体験してもらいたい狙いです。
まとめ
今回のお題は仕様としては単純でしたが、ハンズオンを開催すると、参加いただくチームごとに異なるドメインモデルができ上がります。
ドメインモデルには正解はありません。そのビジネス/システムで何を重要視するのかによって変わります。
そして、何を重要視するのか？それは、深いドメインへの理解でしか判断ができません。
DDDモデリングハンズオンでは、その活動をドメインモデルとソースコードを往復する事で体験してもらいました。
この体験がみなさんの、DDDへの理解の手助けになれば幸いです。
以上です
