👋

Domain Storytelling - 読書感想文

2022/01/09に公開

DDD

はじめに

この記事はDomain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software を最後まで読んだのでその感想文を記したものです。なので本の要約を求めてた方、本の内容について深い考察を求めていた方、ごめんなさい。きっと要望を満たせていません。あくまでポエムとして見てください。

下記に注意事項を列挙しておきます。

読書感想文です。なので個人的な意見や感想が入ってます。
間違ったことを言ってる（書いてある）ことがあります。むしろ多くても不思議ではありません。
本の内容をしっかり知りたいなら本を買いましょう

この本を読もうと思ったきっかけ

ドメイン駆動設計を学び進めて行くと、おそらくドメイン駆動設計を勉強する多くの方も同じことを思うかもしれないですが、コアドメインと境界づけられたコンテキストをどうやって見つけたらいいのか？という疑問が浮かんでくると思います。

多くの書籍やブログでは開発者はドメインエキスパートとのコミュニケーションを重ねユビキタス言語を作りあげることを推奨していると思います。そしてそのユビキタス言語を使って業務を深く理解しコアドメインや境界づけられたコンテキストを見つけるのかと思います。しかし、その考え方が重要なのは理解できますが、実際にドメインエキスパートとどうコミュニケーションを取っていくのが良いのか、という点が私は気になりました。

もちろん環境や文化によってコミュニケーションの取り方が違うので唯一解は無いと思います。したがって、ごちゃごちゃ言ってないで実務経験を積んでトライアンドエラーするのが一番良いのかと思います。しかし、もし効果的な手法があるならば、ぜひ活用してみたいので今回はドメインエキスパートとのコミュニケーションの取り方について調べてみました。

するとDomain Storytellingというモデリング手法を見つけ、ちょうど私の関心ごとマッチしていそうだったので本を読んでみることにしました。

この本を読んだ感想

まず最初にDomain Storytellingを正月休みで一気に通読してみました。その後はこの感想文を書く時に何度か部分的に読み直しをしました。

この本の日本語訳は2022年1月の時点では存在しないので、英語版(原著)を読みました。近年はDeepLなどの優秀な翻訳ツールが存在するので私のように英語が苦手な人間でも読むことが出来ました。

DomainStorytellingとは

Domain Storytellingとは書籍のChapter 1 - What Is Domain Storytelling に次のように説明されています。

Domain Storytelling is a collaborative modeling technique that highlights how people work together. Its primary purpose is to transform domain knowledge into business software. This purpose is achieved by bringing together people from different backgrounds and allowing them to learn from each other by telling and visualizing stories.

ドメインストーリーテリングは、人々がどのように一緒に働くかを強調する協調的なモデリング手法である。その主な目的は、ドメインナレッジをビジネスソフトウェアに変換することです。この目的は、異なる背景を持つ人々が集まり、ストーリーを語り、視覚化することで互いに学び合うことで達成されます。(DeepL翻訳)

この説明を見た最初に感想としてはドメイン駆動設計のコアドメインの探求の考え方にかなり近いし、Domain Storytellingという名前自体がドメイン駆動設計を意識していると思いました。それもそのはずで著者の一人のHenning氏はDomain Driven Design Distilledのドイツ語版に関わっていてる方でした。そのため、Appendixに書かれていますが、Domain Storytellingという意図的にドメイン駆動設計に近い名前にしています。

Domain Storytellingはドメイン駆動設計と関係が深いということが分かりました。となるとDomain Storytellingを使ったモデリングはドメイン駆動設計で開発をすすめる際に何かしらの恩恵を得ることができるはずです。本書を読み進めて行った結果、Domain Storytellingを使ってモデリングすると以下の２つの発見に役立つ可能性があるのでは？っと思いました。

コアドメインの発見
境界づけられたコンテキストの発見

１つ目はコアドメインの発見に役立つかもしれないということです。何故そう思ったかというのは次の文(Chapter 3のScenarios in Domain Storytellingの節)を読んだときです。

We recommend you start with modeling the default case—the “80% case”—and the “happy path” first.

まずはデフォルトのケース（「80%のケース」）と「ハッピーパス」のモデリングから始めることをお勧めします。(DeepL翻訳)

この１文が示している通り、Domain Storytellingは対象ドメインをざっくりと理解するための手法だと思います。Domain Storytellingはアクティビティ図とも似ていますが根本的に違うのはDomain Storytellingには条件分岐が存在しません。つまり網羅的にフローを把握することには注力せず、対象ドメインのコアとなる場所はどこなのか？を問うことに注力した手法だと思います。そして「ハッピーパス」はその経路に関わる人や物がコアドメインと関連が強くあるということになります。一方でハッピーパス以外のエッジケースに関しては、Domain Storytellingでモデリングすると費用対効果が悪いので利用すべきではないとも本書で述べています。

２つ目は境界づけられたコンテキストの発見に役立つかもしれないということです。会社での物品購入の業務フローを例に考えてみます。業務用のパソコンを買いたいと思っているある社員がいたとします。その社員はパソコンを購入するには購入候補をリストアップしその中から購入するものを選択します。そして予算内を確認するために経理に確認し、上長から承認をもらった上で、購買に発注依頼を行います。この一連のアクティビティの中で多くの登場人物が出てきますが、Domain Storytellingでモデリングを行うと登場人物から見るとどういう視点でストーリーが見えているのか俯瞰することができます。

なぜ登場人物(アクター)の視点を意識するのかについてはChapter 10のFinding Boundaries-A Heuristic for Finding Subdomainsで次のように説明しています。

You can use domain stories to find out which activities—from a domain expert’s perspective—belong together. Thus, the domain can be broken down into subdomains.

ドメインストーリーは、ドメインの専門家から見て、どのアクティビティが一緒になっているかを見つけるために使用されます。このように、ドメインはサブドメインに分解することができる。(DeepL翻訳）

つまり著書らはアクターの立場から業務フローを観測すればそこに境界づけられたコンテキストが存在する、っっと考えているのだと思います。実際にDomain Storytellingで境界づけられたコンテキストの探索を試したわけではないので、これが効果的かは疑問ですが、少なくとも良い判断材料の１つになるのではと思いました。

DomainStorytellingの例

文章だけだとDomain Storytellingが何なのか分からないと思うのでここで少し説明します。

使用するアイコン

実際にDomain Storytellingの例をdomainstorytelling.orgのQuick Startから引用して以下に示します。人やパソコンの形をしたオブジェクトが「アクター」と呼ばれるもので、吹き出しやドキュメントのようなアイコンは「ワークオブジェクト」と呼び、アクターの行動によって作用するオブジェクトです。矢印は「ワークフロー」を表していて英語表記の場合は動詞か前置詞が使われることが多いです。ストーリーの時系列はワークフローの数字が表しています。

この例では映画館でのお客と受付とのやりとりのハッピーパスを表しています。

https://domainstorytelling.org/quick-start-guide

モデリングの進め方

モデリングはモデレーターと呼ばれる人が進行役を務めドメインエキスパートに業務のデフォルトケースをヒアリングしていきます。ヒアリングした内容はモデラーがドメインストーリーとして記述していきます。そしてアクターやワークオブジェクトのアイコンの表現にはピクトグラムを使用しワークフローには単語を添えます。このようにヒアリングして理解した内容を文字と絵でフィードバックすることでドメインエキスパートととの認識の差を埋める工夫しているのがDomain Storytellingの特徴なのだと思います。

モデリングの際の注意点

Domain Storytellingを行う際の注意点を以下に列挙します。すべて本に記載されている内容なので詳細は書籍で確認しましょう。

アクターから別のアクターへは直接繋がらない
戻りのワークフローは書かない
同じアクターやワークオブジェクトは書かない
条件分岐やバリエーションは書かずに別のストーリーとして扱う
エッジケースや留意事項は注釈(annotation)を付け加える

アクター同士は直接ワークフローで繋がりません。何故ならアクターの行動はワークオブジェクトで表現し、それが別のアクターへ渡されるという表現になるからです。物質的なワークオブジェクトでない場合、例えば上の図の③のような口頭でのメッセージなど、それも吹き出しのアイコンなどを使って表現します。

戻りのワークフローを書かないのは、アクターから別のアクターへのワークフローはセンテンス（文）として表現しているからです。上の図の①を例に取ると「Customer asks for reservation (to) Cashier（お客様がキャッシャーに予約を依頼する）」という文章になります。そのため戻りのワークフローを書くとこの表現がおかしくなるので書きません。同じ考えでアクターやワークオブジェクトも重複しないようにし、ワークフローとアクター/ワークオブジェクトとの繋がりに注視しながらモデリングする必要があります。

また前述の通り、ハッピーパスの発見に集中するため、条件分岐やバリエーションは書きません。
以下のように注釈でカバーします。ストーリーを何パターン作成するかは要件次第なのかなっと思います。

実際にストーリーを書いてみた感想

ここからは本の感想ではなく、実際に自演で現在の業務の一部をストーリーに起こしてみたので、その感想になります。

最初から細かい粒度(fine-grained)でも良さそう

Domain Storytellingではストーリーの粒度(Granularity)はそろえるべきと主張しています。
これはChapter 4のScopeで次のように説明しています。

Always aim for a consistent level of detail throughout a story. Mixing FINE-GRAINED and COARSE-GRAINED activities can be confusing and indicative of a larger problem.

ストーリー全体を通して、常に一貫したレベルの詳細さを目指してください。FINE-GRAINEDとCOARSE-GRAINEDの活動が混在していると、混乱し、より大きな問題があることを示す可能性があります。(DeepL翻訳)

最初はCOARSE-GRAINED(荒い粒度)でストーリーを作成し、深堀りしたい箇所に関してはFIND-GRAINED(細かい粒度)で別ストーリーを作成しドメインを理解する流れを推奨しています。但し、ユースケース記述やUMLのクラス図まで詳細なレベルまで細かくしてはいけなく、あくまでドメインのストーリーを意識する必要があります。

実際に業務でこの考えを適用した場合について考えてみます。多くの場合で新規案件やPJではキックオフが私の会社では行われます。そこで説明資料が用意されていて背景や目的、達成したい事柄などが書かれています。
しっかりと資料が用意された状態からスタートを切るならば、COARSE-GRAINEDのレベルでドメインエキスパートに問いかけても、「それ、説明資料に書いてあるよね？」っと言われる可能性が高いなっと思いました。また私の場合、ドメイン知識０の状態でスタートすることが少ないので、最初からFINE-GRAINEDのレベルでモデリングしたほうが早いような気もしています。

重要なのは１つのストーリーの中でFINE-GRAINEDとCOARSE-GRAINEDが混ざらないことなのだと思いました。

純粋なストーリー(PURE)は逆に議論が進みにくいのでは？

Domain Storytellingではストーリーからシステムを除いた純粋(PURE)な形で表現することを推奨しています。

PURE domain stories are particularly helpful for building new software systems. They allow you to understand a domain without also internalizing the accidental complexity added by existing software.

ピュア・ドメイン・ストーリーは、新しいソフトウェア・システムを構築する際に特に有効です。これにより、既存のソフトウェアによって追加された偶発的な複雑さを内包することなく、ドメインを理解することができます。(DeepL翻訳)

これも私の仕事の場合に限るかもしれませんが、ドメインエキスパートがシステムに関してズブの素人ということがありません。多くのドメインエキスパートが日々業務システムを使って仕事をしています。そのため開発案件も「〇〇〇システムの機能でちょっと相談が」というような流れで始まることが多くあります。

こういうケースにおいてはあえてドメインストーリーからシステムを取り除いてしまうと「あれ？〇〇〇システムはどこいったの？」っというやりとりが多発してしまい、逆に分かりづらいストーリーになるかもしれません。なのでPUREを意識してストーリーを構成しつつも、システムも含むストーリー(DIGITALIZED)を話の流れで自然なら組み込むべきかもしれないと思いました。

ドメインストーリーからコードに落とすのは流石に難しそう

第12章のModeling in Codeではドメインストーリーから実際にドメイン駆動設計におけるエンティティを発見して、それをコードに落とし込むテクニックが紹介されています。

正直言ってはこれは少し無理があると思いました。確かにハッピーパスを探求することでコアドメインを発見することは可能かもしれないし、それをエンティティに具象化できるかもしれません。しかし、その他のエンティティや値オブジェクトの発見を十二分にはできず、また集約ルートに関しては分からないままです。実際にコードに落とし込むには、ドメインストーリーを軸におきつつも、ユースケースの洗い出しやドメインモデル図などが必要になると思います。

書籍の中でも、著者らはDomain StorytellingとUser Story Mappingの組み合わせをよく使っていて、場合によってはUMLなども使用しているとのことでした。なので第12章のModeling in Codeはコアドメインに限定した場合の話なのかなと思います。

おわりに

Domain Storytellingはドメイン駆動設計において有用なツールの１つになりえるのかもしれません。また学習コストが低いので一度覚えれば、すぐに実践に移せるのも利点の１つかもしれません。しかしDomain Storytellingを活用できるケースはある程度限定的な気がするので、Domain Storytellingでモデリングしてみた！という事例が増えることを願っています。

コアドメインや境界づけられたコンテキストの発見はDomain Storytellingに限らず様々な方法があると思います。例えばEvent Stormingなども有用なモデリング手法だと思います。Domain Storytellingとの大きな違いはその名の通りにイベントの流れに注目している点だと思います。Event Stormingではイベントを付箋に書き出しホワイトボードなどに時系列順に貼っていくと思います。そしてそのイベントが何よって引き起こされ、どのアクターがそのイベントに関連しているのかを発見するのだと思います。ストーリーを語れるドメインエキスパートが居なかったり、アクターが不明瞭などの場合はEvent Stormingのほうが良いのかもしれないと思いました。

今後は他のモデリング手法を学びつつ、要件定義～基本設計あたりをしっかりと勉強してみようかなっと思いました。モデリングは奥が深い分、学習して楽しいですね（自分だけ？）。