<< ドメイン駆動設計 : 第IV部「おおきな設計」Strategic Design | main | Bounded Context パターン : ドメインの分離独立を徹底する >>

コンテキストのモデリング

エバンスは、去年3月のプレゼンテーション

What I've learned about DDD since the book

で、Domain-Driven Design(DDD)の14章の Bounded Context パターン、Context Map パターン、15章の Core Domain パターンは、DDD の基本コンセプトとして、3章とか、もっと最初に書くべきだった、というようなことを言っています。

このエバンスの発言は、個人的には「何をいまさら」というのが私の正直な気持ちだった。

だって、開発プロジェクトのスタートでは、「コンテキスト図」を書いて、システムを取り巻く環境や、システムの基本目的を明らかにするのが、あたりまえだから。

コンテキスト図を描き始めたきっかけ


もっとも、自分たちのプロジェクトでは、私以外のメンバーは、一年前までは「コンテキスト図」なんて言葉も知らなかったのが実情。

私が「コンテキスト図」という言葉を覚えたのが、ウォータフォール式のプロジェクトだった。
今とりくんでいる、軽量で反復を重視した開発手法とは、なじまないと思い込んでいた。

ところが、ある人が紹介してくれた、リレーションシップ駆動要件分析(RDRA) という要件分析のやり方を知ってから、

「そうか、やっぱりコンテキストモデルから出発するのが良いやり方なんだ」

ということを再認識。

RDRAを提唱されている神崎さんのセミナーに参加してみて、その実践的なやり方、現場のさまざまな経験から生まれた、ノウハウや考え方は、ほんとうに勉強になりました。

ウォーターフォールのような重厚長大なやり方ではなく、もっと現代的な、反復しながらモデルを成長させていくアジャイルなやり方でも、「コンテキスト図」を書くことから始めるのが、良さそうだと。

神崎さんの書かれた


を参考に、「コンテキスト図」を書きながら、コンテテキストモデルを作成することから現場でトライアル開始。

RDRAは、上流工程でやるべきこと、押さえるべきポイントを、体系的に、具体的に教えてくれます。
私たちも、まだまだ、RDRAごっこのレベルですが、その効果には確かな手ごたえを感じています。

RDRAのコンテキスト図のサンプル


こういう簡単な図を書くことが、コンテキストのモデリングの出発点というわけです。

RDRAコンテキストモデル


ポイントは4つ
・全ての関係者をアクターとして洗い出す
・全ての外部システムを洗い出す
・システムの名前をつける
・システムの目的をノートで書く

とっても単純に見えますね。
手書きで数分で描ける程度の作業。

実際にやってみると


関係者で、実際にコンテキスト図を描いてみると、みんなの理解がばらばらだったことには、かなり衝撃を受けました。

・システム名すら一致しない
・目的がかけない
・アクタの見落とし
・アクターの名前がばらばら
・外部システムの見落とし
・外部システムの名前がばらばら
...

こんな状態で「ドメインモデリング」だの「ユビキタス言語」だの言っても、良い結果がだせるわけありませんよね。

アクターを見落としていたり、アクターの名前(概念の捉え方)が違う人たちが集まって、ドメインオブジェクトの議論をしたって、かみ合うわけがない。

「コンテキスト図」を描いて話しをしてみると「基本事項の理解の不足、食い違い」が明らかになった。

これは、大きな発見だし、収穫でした。

コンテキスト図は、プロジェクトの初日に描きますから、その時点で、こういう課題を発見できちゃうのは、すばらしいことです。

コンテキスト図を描くようになっても、メンバーの理解が劇的に改善できたとは、正直いって、思えません。

でも、「理解の不足」「理解の食い違い」を、早期に発見できる手段を手に入れた効果は絶大です。

それ以降のモデリング、設計、実装で、いろいろな議論を進める時に、原点、つまり「コンテキスト図」に戻って、目的や基本価値を再確認することで、重点課題の意識あわせや、設計の選択肢の選択基準の議論などが、ずいぶん、わかりやすくなった。目に見える形になった。

メンバーの間で、なぜ、そう考えるか?、なぜ、そちらを選択するか?という議論やその結果に、論理性がでてきて、納得感が高まった。

DDD の14章にでてくるプロジェクトの失敗例で 「Charge(課金)」オブジェクトが二つの異なる意味で使われていた、というケースも、コンテキスト図を描いて登場人物(アクタや外部システム)を、みんなで共通理解にしておけば、

・(会員に)課金する側の視点での Charge オブジェクト
・(仕入れ先から)課金された料金を支払うための Charge オブジェクト

を混同したり、まちがって利用することは、簡単に防げたと思う。

コンテキスト図は話しをするネタ


プロジェクトの基本目的や、重要課題を伝える時に、プレゼン資料と口頭で、概念的な言葉を並べても、なにも起きません。開発メンバーの多くは、たぶん、頭の中を素通り。

ところが、不思議なもので、UML図っぽい絵にすると、結構、話に参加してくるようになる。

この効果は大きいですね。

また、コンテキスト図レベルだと、でてくる用語は少なく、かつ、重要な基本事項ばかり。

業務の専門家と、ソフトウェアの専門家の間の言葉の違い、ものごとの捉え方のギャップを発見して、修正する、「ユビキタス言語」の開発のスタート地点としては、「コンテキスト図」をネタにした議論やQ&Aは、かなり効果があります。

ドメイン駆動設計の実践の出発点として、「コンテキスト図」を描く事から始めるのが、良いやリ方だと思います。

いろいろなコンテキストモデル


私たちは、RDRAを参考に、コンテキスト図を描いていますが、厳密な描き方のルールがあったり、その通りに描かないとダメ、というものでないと思います。

関係者で、プロジェクト、開発システムの基本事項を理解し、共有するための、単なる手段ですから、自分たちにあったやり方にカストマイズして使うのが、実践的なやり方ですね。

RDRAベースの実践例


RDRAを参考に実践されている例として、例えば、
コンテキストモデル(要点をひとつのモデルに集約し全体を俯瞰)
があります。

RDRAの教科書的な説明からすれば、だいぶはずれているのかもしれませんが、要点を押さえるための道具としては、とても実践的でわかりやすいやり方だと思います。

プロジェクトコンテキスト、運用コンテキスト


RDRAと比較的似ている考え方・やり方としては、こんなものもありますね。
利害関係者の目的を可視化するプロセス

DFD系、ユースケース系


あるいは、DFD(データフローダイヤグラム)系のコンテキストモデルや、ユースケース中心のコンテキストモデルの例もあります。

対象業務のコンテキスト

システム概念図


システムの全体像を説明する道具としては「システム概念図」と呼ぶような図もあります。

ウェブ型損保基幹システムパッケージシステム概念図

興味のある方は、 コンテキスト図 とか システム概念図 を、Google で画像検索すると、いろいろな描き方の例を見ることができます。

コンテキストを関係者で共有する


関係者で、コンテキストを共通理解にすることからはじめましょう。
プロジェクトの途中で、何回も、原点に戻って、コンテキストの共有度を高めましょう。

・システムの目的
・利害関係者は誰か
・彼らの主要な関心事は何か
・接続すべき外部システムは何か
...

ここを共有できているチームは、良い仕事ができるに決まっていますね。

こういう背景、目的、外部環境の理解が、メンバー間で食い違ったままのチームで、モデリング、設計・実装を進めることは、そら恐ろしい。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
   1234
567891011
12131415161718
19202122232425
262728293031 
<< March 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM