<< 実践 ICONIXプロセス : 業務と技術の視点の違い? | main | 実践 ドメインモデリング : 業務側の強み+技術側の強み >>

実践 ICONIXプロセス : 業務系メンバーのドメインモデル

業務系のメンバーのドメインモデルは、業務用語はたくさんでてくるけど、粒度や性格がばらばら。構造もはっきりしないことが多い。

業務フロー図や画面フロー図を描いてもらうと、わかりやすい図を書いてくれる人が多い。 

業務系の人のドメインモデルへのフィードバックは、業務の手順や画面にマッピングしながら話すと通じやすい。

ドメインモデルという業務プロセス図?

業務の順番で、情報の発生順を少し意識してもらうだけで、ぐっとモデルが整理できる。
業務プロセスのはじめから存在する情報と、プロセスの後のほうでしか発生しない情報とを考えて、左から右に並べてもらう。

上下は、アクター別に整理してもらう。業務プロセス図のスイミングレーンですね。

クラス図といいながら、業務プロセス図的に描くわけです。 もちろん、ドメインモデルは静的な構造なので、時系列や登場人物のスイミングレーンを意識しすぎると、問題もあるんだけど、大きな整理のヒントという意味では、とても有効。

ドメインモデルという画面構成図

なんども書いていますが、ドメインモデルの集約関係は、画面に実装すると、
・同じ画面で表示する情報のグループ

・ある画面からリンクで遷移する画面遷移
になります。

集約関係の中心( Aggregates のルート ) は、この問題領域の中核の情報、画面であるはず。

もし、集約ルートのオブジェクトが、この問題領域の中核としてしっくりこない場合は、モデルを見直し、修正しましょう。

ある視点から見れば正しい構造であっても、現在の問題を正しく表現できていないということです。重要でない関係に注目しちゃっている。

集約ルートのオブジェクトの表示画面、入力画面ができてしまえば、ソフトウェアの主要部分が完成。それだけでも、そこそこ役立つ。
これが正しいドメインモデルの集約関係。

コメント
コメントする









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