初期のドメインモデリングは、システムの全体像のデッサンに不可欠な実践のひとつ。
「どんな情報を扱うシステムか」という「情報の視点」を中心にして、機能と並行性を視野に入れて、システムの全体像を、A4一枚のクラス図にまとめていく。
「概念モデリング」とか、「業務の用語集作成」とほぼ同じ。
業務で扱う情報名や業務上の処理(機能)名を、クラス図として描いていく。
UMLツールでクラス図を書くと、それぞれのクラスは、線の太さや色が同じになる。
これだと、かなり平坦なデッサンになり、あまり役に立たない。
ドメイン、つまり、業務の視点、業務から見た重要度や、関心の強さを光源にして、強く光る部分、弱く光る部分、陰影などを描きこめば、モデルが、立体的に、生き生きとしてくる。
ドメインという光源から、陰影や強弱をつけた絵は、関係者の認識合わせに、とても役にたつ。
線の色も太さも同じ四角がならんだクラス図だと、業務の言葉さえ並んでいれば、なんとなく、そんなもんだろうで終わってしまう。
「重要な関心事オブジェクト」「注意すべきオブジェクト」という色分け、描き分けをしてみると、人によって、捉え方が違っているのが一目瞭然になる。
開発者は、プロジェクトの初期では、どのドメインオブジェクト(どの業務の用語)も同じに見えている。
どこから手を付けてもいっしょに見えるし、どのオブジェクトの分析・設計に、時間とエネルギーを使うべきか判断できない。
ドメイン(業務)という光源からあてた光で、めりはりをつけたクラス図を描けば、業務のエキスパートの重要な関心事、業務のややこしい部分を、プロジェクトの初期で、関係者で共有できる。
共有できれば、開発全体の軸や方向感がでてくる。チームが良い成果を達成するための羅針盤になる。
ドメイン駆動設計(DDD)の Highlighted Core パターンですね。
ドメインから光をあてた結果の、光の強弱は、クラスアイコンの背景色、線の太さ、色などで、描く。
あまり、凝らないほうが良い。
背景色だと、白、黄色、グリーンくらいで十分。
線の色や太さはこらないほうが良い。描きわける労力に比べ、情報の伝達効果はいまひとつ。
もちろん、約束事を決めて、同じ色は同じ意味にする。
Enterprise Architect のような UML ツールだと、ステレオタイプを色で視覚化できるので、core とか、subject とか、主題であることを宣言するステレオタイプを定義して、色設定するといいかもしれない。
陰影のつけ方は、アイコンに影をつけるわけではない。
ドメインから光をあてたとき、そのクラス図で影になる部分とは、クラス図の表面ではなく、裏側に何かある、ということ。
「何かある」ということを、明示するために、便利なのが「ノート」。ようするに、注釈ですね。
注釈がついた、クラスには、何かあるぞ、ということになる。
初期の段階では、「ここはなにかあるかも?」という程度のメモでもよい。
関心事の重要性で色分けし、注意すべきクラスには、ノートがついているクラス図で、関係者で、ドメインの概念、構造を、共有できると、あとあと、つまらない、手戻りが激減します。
業務で重要な部分、注意すべき部分を、ソフトウェアの開発者が最初から、きちんと理解して、開発を進めているのだから、大きなブレは起きない道理です。
逆に、ここらへんの認識合わせが、ずれたままだと、ソフトウェアは動くかもしれないが、中身は、かなり、業務モデルとはずれた、ねじれた実装になっている可能性が高い。
ドメイン(業務)の概念モデルと、ソフトウェア実装の構造がねじれていると、変更に弱く、わけのわからない副作用が発生しやすいソフトウェアになる。
業務の構造と概念を丁寧に反映したソフトウエアだと、変更要求も、合理的だし、コードの変更も局所的に、安全にできるようになる。
初期の概念モデリング(ドメインモデリング)で、ドメイン(業務)を光源に、クラス図に色分けとノートで注釈したものを意識して作成し、共有することが、役に立つソフトウェアを作る、基本テクニックの一つ。
業務の光で、クラス図を照らして、強弱・陰影をつけた場合、重要なクラスは、技術者から見たら、単純で、退屈なクラスに見えることが多い。
うまくいっているビジネスほど、ほんとうに重要なことは、精査され、磨き上げられているので、初期のモデルをみる限りは、その中核オブジェクトは、単純に見えることがある。
で、単純に作ると、大失敗。
重要なドメインオブジェクト、業務の関心事であるオブジェクトの分析・設計には、細心の注意が必要。
そのオブジェクトが表現している、業務の関心事は、実際の業務の中で、さまざまなルールや手順が、なかば無意識に適用されている。また、重要な関心事であるだけに、たまにしか起きないような例外的な状況の時は、どうするかとかのノウハウが、業務のエキスパートの頭の中に、しっかり入っている。
ところが、これらのルール、手順、例外対処ノウハウなどは、業務のエキスパートが、事前に、明示的に語ることはまずない。 彼らにとっては、ある意味、前提知識みたいな話だし、あまり意識せずに、それをやっているからこそ、エキスパートなわけで、いちいちそんなことを意識して考えていたのでは仕事にならない。
業務に役に立つ道具を作るためには、そいういうエキスパートの知識をなんとか引っ張り出して、コードに実装しなくちゃいけない。
そのためのテクニックが、ドメインモデリング。概念クラス図。
業務で重要な関心事クラスは、実装は単純なクラスかもしれません。
でも、その背景にある、ビジネスルール、業務知識を、適切にキャッチするのは、かなり難易度が高い。
初期の概念モデリングで、ドメインの中核オブジェクト、業務の重要な関心事オブジェクトを特定できたら、そこが出発点。
楽勝に見えても、細心の注意を払って、分析・設計を進めること。
エキスパートとのやり取りで、ちょっとでも違和感を感じたら、がんばって掘り下げること。
ハイライトされた重要オブジェクトのまわりには、大切な業務知識が山のように埋まっている。
それを、丁寧に掘り出すことで、業務の役に立つソフトウェアを作ることができる。
重要な業務知識のありかの嗅ぎ付け方、掘り出し方が、よいソフトウェアづくりに、必須のスキル。
クラス図に色やノートを使って、強弱・陰影をつけて、業務のエキスパートや、開発者どうしで、認識合わせを丁寧にやれば、重要な業務知識のありかは、容易に見つけることができる。
ただし、そのまわりに埋まっている業務知識の掘り出しは、そう、簡単ではない。
ここに、いろいろ埋まっているんだ、という革新を持って、分析・設計を進めれば、ある日、突然、価値のある業務知識を見つけることができる。 ドメイン駆動設計(DDD)の、ブレークスルーパターンですね。
Evans も書いているように、いつ、どんなブレークスルーが起きるかは、予測不能。地道に、基本的な分析・設計を繰り返すのみ。
でも、あちこちを、手当り次第にほっていたのでは、いかにも効率が悪い。
システム全体のデッサンで、初期の概念モデルに、業務の光をあてて、強弱・陰影をつけることで、どこを掘ればよさそうかのあたりが、つけば、ソフトウェアの価値をもっとも高めることができるポイントに、時間とエネルギーを投入できる。
それが、良いシステムのデッサンのコツであり、やるべきこと。
ブレークスルーが起きるタイミングは予測できないが、ブレークスルーが起きる場所は、分析モデリングの初期からある程度、確信をもって、予想できる。 業務の重要な関心事を表現する、中核クラス。そこに、ブレークスルーのネタはころがっている。
「どんな情報を扱うシステムか」という「情報の視点」を中心にして、機能と並行性を視野に入れて、システムの全体像を、A4一枚のクラス図にまとめていく。
「概念モデリング」とか、「業務の用語集作成」とほぼ同じ。
業務で扱う情報名や業務上の処理(機能)名を、クラス図として描いていく。
光源はドメイン
UMLツールでクラス図を書くと、それぞれのクラスは、線の太さや色が同じになる。
これだと、かなり平坦なデッサンになり、あまり役に立たない。
ドメイン、つまり、業務の視点、業務から見た重要度や、関心の強さを光源にして、強く光る部分、弱く光る部分、陰影などを描きこめば、モデルが、立体的に、生き生きとしてくる。
ドメインという光源から、陰影や強弱をつけた絵は、関係者の認識合わせに、とても役にたつ。
線の色も太さも同じ四角がならんだクラス図だと、業務の言葉さえ並んでいれば、なんとなく、そんなもんだろうで終わってしまう。
「重要な関心事オブジェクト」「注意すべきオブジェクト」という色分け、描き分けをしてみると、人によって、捉え方が違っているのが一目瞭然になる。
開発者は、プロジェクトの初期では、どのドメインオブジェクト(どの業務の用語)も同じに見えている。
どこから手を付けてもいっしょに見えるし、どのオブジェクトの分析・設計に、時間とエネルギーを使うべきか判断できない。
ドメイン(業務)という光源からあてた光で、めりはりをつけたクラス図を描けば、業務のエキスパートの重要な関心事、業務のややこしい部分を、プロジェクトの初期で、関係者で共有できる。
共有できれば、開発全体の軸や方向感がでてくる。チームが良い成果を達成するための羅針盤になる。
ドメイン駆動設計(DDD)の Highlighted Core パターンですね。
クラス図に光の強弱と陰影をつける
ドメインから光をあてた結果の、光の強弱は、クラスアイコンの背景色、線の太さ、色などで、描く。
あまり、凝らないほうが良い。
背景色だと、白、黄色、グリーンくらいで十分。
線の色や太さはこらないほうが良い。描きわける労力に比べ、情報の伝達効果はいまひとつ。
もちろん、約束事を決めて、同じ色は同じ意味にする。
Enterprise Architect のような UML ツールだと、ステレオタイプを色で視覚化できるので、core とか、subject とか、主題であることを宣言するステレオタイプを定義して、色設定するといいかもしれない。
陰影のつけ方は、アイコンに影をつけるわけではない。
ドメインから光をあてたとき、そのクラス図で影になる部分とは、クラス図の表面ではなく、裏側に何かある、ということ。
「何かある」ということを、明示するために、便利なのが「ノート」。ようするに、注釈ですね。
注釈がついた、クラスには、何かあるぞ、ということになる。
初期の段階では、「ここはなにかあるかも?」という程度のメモでもよい。
関心事の重要性で色分けし、注意すべきクラスには、ノートがついているクラス図で、関係者で、ドメインの概念、構造を、共有できると、あとあと、つまらない、手戻りが激減します。
業務で重要な部分、注意すべき部分を、ソフトウェアの開発者が最初から、きちんと理解して、開発を進めているのだから、大きなブレは起きない道理です。
逆に、ここらへんの認識合わせが、ずれたままだと、ソフトウェアは動くかもしれないが、中身は、かなり、業務モデルとはずれた、ねじれた実装になっている可能性が高い。
ドメイン(業務)の概念モデルと、ソフトウェア実装の構造がねじれていると、変更に弱く、わけのわからない副作用が発生しやすいソフトウェアになる。
業務の構造と概念を丁寧に反映したソフトウエアだと、変更要求も、合理的だし、コードの変更も局所的に、安全にできるようになる。
初期の概念モデリング(ドメインモデリング)で、ドメイン(業務)を光源に、クラス図に色分けとノートで注釈したものを意識して作成し、共有することが、役に立つソフトウェアを作る、基本テクニックの一つ。
重要度と分析・設計の難易度
業務の光で、クラス図を照らして、強弱・陰影をつけた場合、重要なクラスは、技術者から見たら、単純で、退屈なクラスに見えることが多い。
うまくいっているビジネスほど、ほんとうに重要なことは、精査され、磨き上げられているので、初期のモデルをみる限りは、その中核オブジェクトは、単純に見えることがある。
で、単純に作ると、大失敗。
重要なドメインオブジェクト、業務の関心事であるオブジェクトの分析・設計には、細心の注意が必要。
そのオブジェクトが表現している、業務の関心事は、実際の業務の中で、さまざまなルールや手順が、なかば無意識に適用されている。また、重要な関心事であるだけに、たまにしか起きないような例外的な状況の時は、どうするかとかのノウハウが、業務のエキスパートの頭の中に、しっかり入っている。
ところが、これらのルール、手順、例外対処ノウハウなどは、業務のエキスパートが、事前に、明示的に語ることはまずない。 彼らにとっては、ある意味、前提知識みたいな話だし、あまり意識せずに、それをやっているからこそ、エキスパートなわけで、いちいちそんなことを意識して考えていたのでは仕事にならない。
業務に役に立つ道具を作るためには、そいういうエキスパートの知識をなんとか引っ張り出して、コードに実装しなくちゃいけない。
そのためのテクニックが、ドメインモデリング。概念クラス図。
業務で重要な関心事クラスは、実装は単純なクラスかもしれません。
でも、その背景にある、ビジネスルール、業務知識を、適切にキャッチするのは、かなり難易度が高い。
初期の概念モデリングで、ドメインの中核オブジェクト、業務の重要な関心事オブジェクトを特定できたら、そこが出発点。
楽勝に見えても、細心の注意を払って、分析・設計を進めること。
エキスパートとのやり取りで、ちょっとでも違和感を感じたら、がんばって掘り下げること。
ハイライトされた重要オブジェクトのまわりには、大切な業務知識が山のように埋まっている。
それを、丁寧に掘り出すことで、業務の役に立つソフトウェアを作ることができる。
重要な業務知識のありかの嗅ぎ付け方、掘り出し方が、よいソフトウェアづくりに、必須のスキル。
クラス図に色やノートを使って、強弱・陰影をつけて、業務のエキスパートや、開発者どうしで、認識合わせを丁寧にやれば、重要な業務知識のありかは、容易に見つけることができる。
ただし、そのまわりに埋まっている業務知識の掘り出しは、そう、簡単ではない。
ここに、いろいろ埋まっているんだ、という革新を持って、分析・設計を進めれば、ある日、突然、価値のある業務知識を見つけることができる。 ドメイン駆動設計(DDD)の、ブレークスルーパターンですね。
Evans も書いているように、いつ、どんなブレークスルーが起きるかは、予測不能。地道に、基本的な分析・設計を繰り返すのみ。
でも、あちこちを、手当り次第にほっていたのでは、いかにも効率が悪い。
システム全体のデッサンで、初期の概念モデルに、業務の光をあてて、強弱・陰影をつけることで、どこを掘ればよさそうかのあたりが、つけば、ソフトウェアの価値をもっとも高めることができるポイントに、時間とエネルギーを投入できる。
それが、良いシステムのデッサンのコツであり、やるべきこと。
ブレークスルーが起きるタイミングは予測できないが、ブレークスルーが起きる場所は、分析モデリングの初期からある程度、確信をもって、予想できる。 業務の重要な関心事を表現する、中核クラス。そこに、ブレークスルーのネタはころがっている。