コンテキストマッピングによる戦略的ドメイン駆動設計

いいね

原文(投稿日:2009年11月25日)へのリンク 翻訳者:和智 右桂

導入

オブジェクト指向モデリングに対する多くのアプローチが、アプリケーションの規模が大きく複雑になった時にスケールアップしないということは多くあります。コンテキストマッピングはドメイン駆動設計(DDD:Domain Driven Design)が持つツールの1つである汎用的なテクニックで、アーキテクトや開発者がソフトウェア開発プロジェクトにおいて直面するさまざまな複雑さを管理する際に役に立ちます。その他の良く知られているDDDパターンとは異なり、コンテキストマッピングはあらゆる種類のソフトウェア開発シナリオに当てはまり、開発者が戦略的な決定をする上で役に立つハイレベルの視野を与えてくれます。戦略的な決定には、例えば、特定のプロジェクト環境において完全にDDD型で実装を行うかどうかといったものがあります。

この記事では、境界つきコンテキスト("bounded context")が持つ多くの側面と、ソフトウェア開発プロジェクトにおける重要な意思決定をサポートできるようコンテキストマップを構築するにあたって、境界つきコンテキストをどのように利用できるのかについて考察していきます。

多くのモデルが機能する

ドメイン駆動設計は、アプリケーションのモデルに関して概念的統一性を保つことを非常に重視します。これは、以下に挙げるようないくつかの要素を組み合わせることで実現されます。

• ユーザやドメインエキスパートから頻繁にフィードバックを受けることを重視するアジャイルプロセス。
• 真のドメインエキスパートを得ることと、ドメインエキスパートと創造的な共同作業を行うこと。
• ユビキタス言語によって正確に定義された、共有された単一のモデル(アプリケーションとテストコードにおいても)。
• 学習と調査を推進するような、隠し事のない開かれた環境。

高品質の設計が成長してその価値を提供できるように、安全な場所を作ることが重要です。このような場所があってはじめて、エンティティ("Entity")やバリューオブジェクト("Value Object")および集約("Aggregate")といった典型的なDDDの諸要素が、複雑なドメインモデルに秩序をもたらすことができるのです。ただし、伝統的なDDDのアプローチを漠然とした巨大なドメインモデルに対して盲目的に適用することはできず、それにはモデルの概念的統一性を妥協する必要があります。

図1に示すように、DDDにおけるユビキタス言語の主要な役割として、モデルの統一性をチェックするというものがあります。同じ用語を使うこと、それもあいまいさを排除した形できわめて正確に定義された意味において、ドメインエキスパートとの会話からコードレベルに至るまで一貫させることによって、チーム内の全てのメンバがドメインとソフトウェアに関して同じ考え方を共有できるのです。

図1.ユビキタス言語はモデルを表現するのに用いられる唯一の言語でなければならない。チーム内のメンバは誰もが、個別の各用語についてあいまいさの残らない形で合意せねばならず、翻訳する必要がないようにしなければならない。

コードはモデルを表現する主要な形態です。要件なり設計の一部分をとらえる過程においては、それ以外の成果物も必要になるかもしれません。しかし、アプリケーションのふるまいと恒常的に同期しているのはコードそれ自体なのです。このようなモデリングの理想郷は、いくぶん脆弱なエコシステムです。前述したような条件が与えられれば実現は可能ですが、むやみに拡大することはできません。概念的統一性を妥協することなく、モデルを拡大することができる最大の範囲が、コンテキスト("context")と呼ばれています。

境界つきコンテキストに踏み込む

ドメイン駆動設計において、コンテキストは次のように定義されています。
「単語や文章が現れる状況で、その意味を定義するもの」
これは一見するとあいまいな定義であるように見えます。期待される大きさや形、あるいはコンテキストの他の特徴について多くを語っていません。しかし、最終的にはこの定義がむしろ正確なものであり、コンテキストとは何かを正確に記述していることが分かるでしょう。しかし、その片鱗を理解するためには、具体例がいくつか必要になります。

例1:同じ用語、別の意味

あいまいさが用語法のレベルで発生している単純な例から見ていきましょう。同じ単語であっても、使用されているコンテキストに応じて異なる意味を持ちます。

ウェブベースの個人金融管理アプリケーション(PFM:Personal Finance Management)を構築していると考えて下さい。このアプリケーションは、銀行口座、株式、預金の管理や予算と支払の追跡などに使うとします。

このアプリケーションにおいて、ドメインの用語である「アカウント」("Account")は別々の概念を意味するかもしれません。銀行取引に関して言えば、アカウントとは口座、すなわち、ある種の論理的な「現金の器」であり、したがってアカウントに対応するクラスに対しては残高や口座番号といった属性を持つことを期待します。しかし、ウェブアプリケーションのコンテキストにおいてアカウントという用語は全く異なる意味を持ちます。これは認証やユーザ証明に関するものになるということです。図2に示すように、対応するモデルはまったく異なるものになるのです。

図2.あいまいさがあまりない場合:アカウントという用語は使用されるコンテキストに応じて全く異なる意味を持つかもしれない

これはおそらく、アプリケーションのモデリングをする上で行き当たるあいまいさとしては、もっともシンプルな例でしょう。すなわち、同じ用語がコンテキストに依存した2つの異なる意味を持つというものです。この問題はたいていクラス名に何か接頭語を追加して名前空間を区切ることで解決されます(接頭語は名前に付くことも、パッケージの一部になることもあります)。しかし、概念的なレベルでは2つの異なるコンテキストが存在しているということを意識しなければなりません。両者の違いが十分に大きくて開発者が間違うことがないこともありますが、この違いがよりわずかであることも少なくありません。

残念ながら、クラス名の水準で作業することが常に有効な解決策になるわけではありません。銀行取引のドメインにおいては、「銀行取引アカウント("Banking Account")」という用語が違う意味を持って既に存在するかもしれませんし、あるいはドメインエキスパートが「アカウント」こそが正しい用語であると主張するかもしれません。妥協用に何か特定の用語を作り出したいとか、ドメインエキスパートの用語からコードへ翻訳するための補完材料を導入したいといった誘惑に負けないで下さい。ここでは2つの異なるコンテキストに直面しているのです。

最初のコンテキストマップを描く

あいまいであることが妨げになるようであれば、アプリケーション内に2つの異なるコンテキストが存在することを開発チームが意識できるようなツールが必要です。あいまいさというものはユビキタス言語にとっての天敵であり、それは取り除かねばならないのです。あいまいさを取り除く最善の方法は、コンテキストマップ内の境界つきコンテキストを単位としてドメインの構造を明らかにするというものです。シンプルなコンテキストマップを図3に示します。

図3.機能している2つのドメインコンテキストに対するシンプルなコンテキストマップ

ドメイン駆動設計の本において、コンテキストマップは境界つきコンテキストを明確に表現するための主要なツールとされています。基本的な考え方としては、ホワイトボードにコンテキスト境界を描くというものがあります。そこにあるクラスについて対応するドメインの用語で中を埋めてもいいでしょう。これは明確に定義された正確なUML図ではありません。これは不明瞭な状況をマッピングするための便利ツールであり、したがって、いくぶん不明瞭な外見をしている必要があるのです。

例2:同一の概念が異なる用いられ方をする。

もっと混乱するような区別もあります。根底にある概念は同一なのに、異なった使われ方をして、最終的に異なるモデルにたどり着くというものがそれに該当します。銀行取引アカウントのモデルは、図4に示すようなBankingAccountクラスになるでしょう。

図4.BankingAccountクラスの簡易バージョン

PFMアプリケーションによっては、支払の管理もできるでしょうが、その場合は通常支払対象者("Payee")レジストリを保持します。このシナリオでは、1人の支払対象者("payee")は1つまたは複数の銀行取引アカウントに関連づけられるでしょう。しかしこの場合には、支払対象者が持つ銀行取引アカウントの内部について何も知りたくないし、そういったアカウントに対する操作を要求することもできないのです。そうなると、今定義したBankingAccountクラスを用いて支払対象者のアカウントをモデリングすることに意味があるでしょうか?

図5.PayeeクラスとBankingAccountクラス

確かに、合理的には見えるかもしれません。結局のところ同じ概念なのですから。現実世界において私たちのアカウントと支払対象者のアカウントは物理的に同じ銀行の中にあるかもしれません。そうであっても、これが完全に正しいとは思えません。支払対象者の銀行取引アカウントについて何か操作を要求しようとは思っていませんし、何も追跡しようとは考えていないからです。さらに悪いことに、そのようなことをしては、アプリケーションにおける概念的な過ちをおかすことになってしまうでしょう。

それではどうするべきなのでしょうか?再び同じアプリケーション内に2つのコンテキストがあるという状況に行き当たったのです。今回は同一のドメインの概念を別の仕方でモデリングするという結論を出すこともできるかもしれません。明確で区別された2つの用法があり、それぞれが別々のモデルを要求しているからです。BankingAccountクラスはクラスのままとして、それによって特定の操作(預金や引出)を実行する(もしくは追跡する)ことができるようにします。それに対して別クラスであるPayeeAccountはBankingAccountと同じデータ(例えばアカウント番号)を持つこともできますが、もっとシンプルなモデルであり、明確に異なるふるまいを持ちます(例えば、支払対象者の残高にアクセスすることができてはいけません)。図6では用語が明確な意味を持ち、根底にある概念を同じくしながら、アプリケーションにおいて異なる使い方をしている様子を示しています。

図6.BankingAccountクラスとPayeeAcountクラス

このことが全員にとって明らかだという訳ではありません。クラス図ないしUMLモデリングツールで作業している時には、Payeeオブジェクトが属性としてbankingAccountを持つものとして安易にモデリングを開始し、「このクラスは既にある」と考えるかもしれません。条件反射的にコードの重複を排除しようとすることは、時として害をなすこともあるのです。

この例に対してシンプルなコンテキストマップを当てはめると、図7のようになります。この環境に対する理解が向上したらすぐにマップに反映するのだということを付記しておきましょう。この場合では、PFMアプリケーションのコンテキストを銀行取引("Banking")と支払追跡("Expense Tracking")とに分けています。

図7.きわめてシンプルなコンテキストマップ:ドメインモデルの周囲に引かれた境界線は概念的統一性が維持される領域を示している。

この場合、2つのコンテキストには論理的に重なり合う領域があります。銀行取引アカウントという概念はアプリケーションの場所が異なれば、違う使われ方をするのであり、これは機能するモデルを別に作るということを意味します。しかし、この2つのモデルは相互に密接に関連することになりそうです。コンテキスト境界内においてモデルの概念的統一性を維持することを別にしても、コンテキストマップがあれば、異なるコンテキストの間で何が起きているのかについて意識を向けることができます。この場合、同じチームが両方のコンテキストで作業していると想定すると、チーム内の全員が異なるコンテキストが2つあることを意識し、最終的には両方のモデルに現れる用語と概念のための翻訳マップを共有する必要があるのです。

例3:外部システム

問題のPFMアプリケーションについて再考してみましょう。こういったアプリケーションの多くは、金融期間のオンラインサービスとある種のデータ交換ができます。場合によっては、銀行はホームバンキングサービスに対するリアルタイムなアクセスを提供することもありますし、単にユーザが一般的な標準フォーマットで銀行取引明細書をダウンロードできるようにしているだけのことあります。しかし、コンテキストマッピングの考え方からすると、インタラクションとコミュニケーションの方向(一方か双方向か)は対応していません。問題なのは、ここでも、2つのモデルが機能しているということです。図8ではPFM銀行取引アプリケーションがオンライン銀行取引サービスアプリケーションとインタラクトする様子を示しています。

図8.外部にあるアプリケーションとのインタラクションは、コンテキストマップ内に別の境界つきコンテキストを必要とする

2つのモデルが同じデータを表象するように設計されていたとしても、(少なくともある程度は)両者は異なるものです。時間と共に別々の方向に発展するような力が働きますし、異なる目的に従事します。したがって、境界つきコンテキストは分離して作られる必要があります。例1もユーザプロファイリングがサードパーティライブラリを使ってモデリングされていれば、このタイプに入るでしょう。

複数のコンテキストを管理する

アプリケーションが複数のコンテキストにわたるのであれば、その間で起こっていることも管理する必要があります。別々の境界つきコンテキスト間に存在する関係が、プロジェクトに対する重要な洞察を与えてくれることもあります。

把握しておくべき最重要事項の1つが、2つのコンテキスト間の関係の方向性です。DDDでは、アップストリームとダウンストリームという用語を使います。アップストリームコンテキストはダウンストリームコンテキストに影響を与えますが、その反対はありません。この考え方はコードにも適用できますが(相互に依存関係のあるライブラリ)、スケジュールや外部のリクエストに対する応答性といった非技術的要素にも適用できます。この例において、外部システムが私たちが出したリクエストによって変更されることは、明らかにありません。それに対してPFM銀行取引アプリケーションの方は、オンライン銀行取引サービスのAPIが何らかの理由で変更されたら、それに合わせてすぐに変更する必要があります。このことから、PFMのコンテキストがダウンストリームであり、オンライン銀行取引サービスがアップストリームであることがはっきりと分かります。図9は2つのドメインコンテキスト間にあるこの関係を説明しています。

図9.分離されたコンテキスト間にあるアップストリーム/ダウンストリームの関係

外部の要求に応じて、外部システムとコミュニケーションする方法を更新するということは許容できることですが、アップストリームのコンテキストから来る変更に対してはある種の防御が必要でしょう。これは自分たちの銀行取引コンテキストにおける概念的統一性を守るためです。DDDでは、異なるコンテキストがインタラクトする際のやり方を記述し、管理する上で役に立つ組織的なパターンがいくつか説明されています。この状況に最も良く適合するパターンが腐敗防止層(ACL:Anti-Corruption Layer)です。これは、2つのコンテキスト間における変換がコードレベルで明確に行われることを要求するものであり、さらには、それを銀行取引コンテキストの外部境界でやることを求めるものです。これは、JavaからXMLへの変換といった技術的な変換だけではありません。両側にあるモデル間のわずかな差異をすべて管理する場所でもあるのです。コンテキストマップ上にACLを描くと、図10に示すような図になるでしょう。

図10.PFMアプリケーション境界上の腐敗防止層、オンライン銀行取引サービスが自分たちの境界つきコンテキストに進出するのを防いでいる

コンテキストの分離が自然と必要になるのは、外部システムだけに起因するものではありません。既存のレガシーコンポーネントは、容易に発展させることができないモデルを持っているものです。私たちの組織内で保守していても、このようなモデルは別の力に従属することもありますし、現在の私たちとは違うやり方で利用されてきた結果であることもあります。レガシーシステムとインタラクトしなければならない場合には、そのようなシステムが別の境界つきコンテキスト内にある可能性が高いと言えます。

コンテキストマップにおける他の関係はどうでしょう?関係についてのDDDのパターンに従って分類することができるでしょうか?開発が小さなチーム1つだけで行われていると想定すれば、このようなパターンはそれほど興味深いものではありません。しかし、銀行取引や支払追跡が異なるチームでメンテナンスされることになるならば、両者にはパートナーシップ関係が必要になるでしょう。両者はどちらも共通の目的に向かって開発されるのです(また、両者が同じレベルにある以上、アップストリーム・ダウンストリームは意味を持ちません)。ウェブのユーザプロファイリングが外部モジュールによって実現されるのであれば、それを「あるがまま("as-is")」で使うことになるでしょう。これは、私たちはウェブユーザプロファイリングに対してダウンストリームかつ順応者("Conformist")になるということを意味します。

図11.関係パターンをスケッチした後のコンテキストマップ

例4:組織のスケールアップ

これまで、1開発チームにおけるシンプルなシナリオについて考えてきました。これによって、コミュニケーションのコストを無視することができました。チーム内の開発者が皆、「モデルに何が起きているのか」を意識していると(もしかしたら楽観的に)想定することができたのです。それに対して、より複雑なシナリオでは、以下に挙げるような影響因子をいくつか含むことになります。

• ドメインの複雑さ(別々のドメインエキスパートが多く必要になる)
• 組織の複雑さ
• より長いプロジェクト(期間)
• きわめて大きなプロジェクト(工数)
• 多くの関連する外部システム、別のシステム、レガシーシステム
• 巨大なチームや、複数の開発チーム
• 分散されたチームやオフショアのチーム
• 人的要因

これらの要因はどれも、開発チームや組織全般におけるコミュニケーションのあり方に影響を及ぼし、最終的には結果として現れるソフトウェアを形作ります。

単一のチームであれば、特にアジャイル的に同じ場所を共有している環境では、チームメンバ間で情報を共有するのに効果的なやり方が多くあります。例としては、対面の会話、設計を結合させるセッション("joint design session")、ペアプログラミング、ミーティング、情報ラジエータ("information radiator")などが挙げられます。残念ながら、これらの技法はチームの規模や数が増えた場合にうまくスケールアップしません。単一の開発チームの垣根を越えてモデルの概念的統一性を共有するのが難しくなってしまうのです。

結局、1つのモデルについて合意するということはきわめて洗練された形態のコミュニケーションであり、問題に対する共通の理解と可能な解決策に関する似たような考え方を含むものなのです。コミュニケーションがそれほど簡単ではないこのようなシナリオにおいては、実行することの方が合意することよりもはるかに容易になります。このようにコミュニケーションがボトルネックとなった場合の典型的な結末が、同じコードベース内の別々の場所に基本的には同じことをやっているクラスが作られるというものです。

PFMアプリケーションが今や巨大になり、同じアプリケーションの新しい取引モジュールで、他のチーム(Bチーム)が一緒に作業することになったと想定して下さい(私たちはAチームです)。Bチームは別の部屋、別のビル、別の町、あるいは別の会社や国にあるかもしれず、なおかつ完全にこの取引という領域のために作られたものです。以下の例では、Aチームがある程度のコードをBチームと共有しています。両者がコードベースの別々の場所で作業する傾向にあるとしてもです。結果として、Bチームは自分たちが必要とする機能を実装したいくつかのクラス(以下の図12におけるA’)を書きますが、それはすでにAクラスが提供しているものです。

図12.別々のチームが同じコードベースにアクセスしているシナリオでは、モデルの各部分に対して別々の見方をするかもしれない。チームが物理的に分散していることは、チーム間で共有される情報の質に影響を与える。

これはコードの重複であり、あらゆる害悪の根本です!単一の、明確に定義された境界つきコンテキストにおいて、これは特にそうなのです。しかし様々な理由によって、このことは、ある程度大きなプロジェクトであれば、ほとんどすべてにおいて発生します。これは通常、プロジェクトの同一の領域において、あまり明確に分離されていないコンテキストが機能していることの兆候になります。時として、2つのチームに対して継続的に考え方の統一性を合わせるように強いるよりも、ドメインモデルを構築する上では2つのコンテキストを分離する方がより効果的かもしれません。

それでは、マップ上にそれをどう表現すれば良いでしょうか?このコンテキストマップはシステム全体に対する現在の私たちの理解レベル反映しており、何か新しいことを学んだり、環境に変化が起きた時にはすぐに更新されます。現在、私たちは何が起こっているのかを正確に把握しておらず、それが「現在の理解のレベル」です。

図13.現在のあまりうまく分離されていない取引コンテキストについては、より詳細な調査か繊細な設計上の決定が必要になる。

図中の警告サインはそこに何か問題があることを示しています。2つのコンテキストが一部オーバーラップしており、両者の関係が明確になっていないのです。これはおそらく、最初に解決しなければならない領域の1つでしょう。コンテキスト内において継続可能な合意された関係を設定するよう試みなければなりません。関係としては、顧客/供給者("Customer-Supplier")、継続的統合("Continuous Integration")、共有カーネル("Shard Kernel")といったものが考えられます。しかしこれは、次の作業です。コンテキストマップは今日の作業のためのツールです。そして今日のところは問題はまだ閉じられていないので、図中の警告サインは残したままにしておきましょう。

色や影にだまされないでください。これは単にコンテキストマップを印刷に適した形にしたかっただけです。実際のコンテキストマップはごちゃごちゃしたものに見えるでしょう。少なくともあなたのプロジェクトがそうである程度には、です。しかし、この警告サインはコンテキストが明確に分離されていない重要な領域があることを示しています。そして、それについて何かをしなければ、全てが巨大な泥の塊(DDDの組織パターンのうち、もっとも改善の余地があるもの)になってしまうかもしれません。

型にはまらない見方

コンテキストマッピングによって、全体像の中にソフトウェアとは関係のない要素を含む必要が出てきます。これは、結果として伝統的なアーキテクチャ分析であれば「対象外」と考えたような領域に光が当たるためです。

例えば、組織内におけるコミュニケーションの方法は、その結果として生まれるソフトウェアに大きな影響を与えます。一般的に、規模が小さければ、コンテキスト境界を定義する主要な要因となるものは使われ方であるのに対し、規模が大きくなると、コミュニケーションの速度とプロジェクトの組織が重要な要因となってきます。Wikiやe-mail、インスタントメッセージといったツールは、継続的に全員の知識を同期させているチームという幻想を与えるものです。しかし、これが夢にすぎないことは皆が知っています。典型的な大規模プロジェクトにおいて、私たちはブログ的な集合的知性の一部になっておらず、メンバによってはチーム外で何が起こっているのかを全く知らないのです。

巨大な組織においてコンテキスト境界を定義することは、難題ですが得るものも大きな仕事です。多くの場合、チームは機能している別のコンテキストで何が起こっているのかを気にしません。モデルの概念的統一性が崩されるのは、全体像を見ている人が誰もいないか、きわめて少ないからです。コンテキストマップを描くことは、調査活動であり、最初は多くの情報が正しいものではありません。境界は最初あいまいであり、絵全体に対する明確なスナップショットを得るためには何ステップか必要になります。

図14.マップの最新版。これが「最終版」だと期待しないこと。学ぶべきことは常にある。

他のコンテキストも機能しているかもしれません。たとえば取引はオンライン株式照会サービスと接続しているでしょう。しかしそれは取引の問題です!コンテキストマップは私たちを取り巻く環境と整合するものです。そして私たちAチームは銀行取引と支払追跡という領域に関して作業しています。私たちが興味があるのは、直接接続し、ソフトウェアに影響を与え得るコンテキストだけなのです。

より多くの情報をあつめるほど、マップは明確になっていくでしょう。前述した通り、アプリケーション内で別々のモデルが機能しており、モデルの統一性は明確に定義された境界つきコンテキスト内でのみ保持されるということを単純に知るだけでも、ドメインモデリングの視点においては多くの価値があるのです。多くのモデルは成長するに従って統一性を失っていきます。この意味においてコンテキストマッピングがおおいに役に立つのです。

戦略的DDDパターンについて

ここでのパターンという用語の使い方にはわずかな違いがあります。定義は同じく、繰り返し発生する問題に対する実績ある解決法ですが、私たちが選択できる解決方法を表していることはほとんどありません。たいてい、組織の構造はパターンを押し付けるものであり、それに対する私たちの唯一の希望は勝ち目のない状況が始まってしまう前にそれを認識することなのです。時に最善の選択をしたり、既存の状況を変更する機会が与えられることもあります。しかし、意識しなければいけないのは、組織レベルの変化にはプロジェクトのスコープが許さないほど長い期間がかかったり、私たちの能力を単純に超えていることがあるということです。

もしどこから初めて良いか悩んでいたら、開発チームから始めて下さい。チームこそが、おそらくモデルに関する考え方を効果的に共有できる、最大の組織単位でしょう。一旦認識されれば、複数のコンテキストも同じチームで管理できるでしょう。結局のところ、多くはアーキテクチャ上の選択になるのですから。

全てのパターンにおいて、コストはそれぞれ異なって割り当てられます。同じような(コンテキストに関連した)問題を解決するとしても、容易に置き換えられるものではありません。例えば、腐敗防止層はコードレベル(特別な領域)に足跡を残すものですが、組織に対してはほとんど影響を与えません。一方でパートナーシップ、つまり顧客/供給者にはコードはほとんど必要なく、単一のコードベースで作業できますが、効果的なコミュニケーションのチャネルと明確に定義されたプロセスがなければ機能しません。協力的な環境なくしてパートナーシップを設定しようとするのは、明らかに失敗する戦略です。

結論

コンテキストの元々の定義は「単語や文章が現れる状況で、その意味を定義するもの」でしたが、それが実に正確であることが明らかになりました。そして、設計レベルからアーキテクチャおよび組織レベルに至るまで、その正確さと効果を失わずにスケールアップできることも分かりました。しかし、筋の通った「一貫性への要求」があっても、モデルを漠然と拡張することはできません。境界つきコンテキストは明確に定義された安全な場所を提供し、モデルが概念的統一性を犠牲にすることなくその複雑さを成長させることができるようにします。

副作用として、大規模プロジェクトに適用されると、コンテキストマップは組織内に存在する暗黙的な境界も見えるようにします。プロジェクトが立ち向かわなければならない状況についての、加工されていない生き生きとしたスナップショットを提供するのです。優れたコンテキストマップは、あなたを阻害するような余分なものの絵も見せるかもしれません。組織が、意識的であれ無意識的であれ、あなたのプロジェクトの成功を阻害するように動いているかどうかを、プロジェクトが開始する前に分かるかもしれないのです。

コンサルタントとしては、顧客のプロジェクトの全容における重要な詳細を素早く把握する上で、コンテキストマッピングが信じられないほど役に立つことが分かっています。そしてこれは、戦略的設計の支援ツールでもあります(マップというものはそういうものですが)。コンテキストマップはシステムの総体的な概要を提供してくれるものであり、これはUMLやアーキテクチャを示す図が完全に取りこぼしているものです。コンテキストマップによって、「大規模な希望に満ちた考え」に対して資金を無駄に使うことなく、求められるシナリオにおいて本当に必要な判断に注力することができるようになるのです。

著者について

Alberto Brandolini氏はITコンサルタント兼トレーナであり、ソフトウェア開発におけるオールラウンドなアプローチを持っています。氏は、イタリアを拠点とするコンサルティングおよびソフトウェア開発会社であるAvanscopertaの創設者兼オーナーです。また、イタリアのコミュニティにおけるDomain Driven DesignとGrailsの推進者でもあります。Brandolini氏の思想をフォローするには、英語のブログであるZiobrando's Lairやtwitterを参照して下さい。

関連記事:

• デベロップメント
• 設計/アーキテクチャ
• デザインパターン
• ドメインモデリング
• Domain Specific Languages
• 設計
• MDA
• Domain Driven Design
• Architecture
• Patterns

あなたのメールアドレスはこちら

国を選んでください。 選択してください InfoQ.com がプライバシーポリシーに従って私の個人情報を扱うことに同意します。

We protect your privacy.