<< イベント駆動のアーキテクチャ 【これから重要になるパターン】 | main | state ソーシング、 event ソーシング 【スタイルの選択肢】 >>

リレーションシップ駆動要件分析(RDRA)の実践

採用支援の新サイトの構築プロジェクトが始まった。

* 仕事を探して応募するためのジョブサイト
* 求人情報を登録するアプリ
* 応募者と採用側の連絡アプリ
* 採用側の応募者管理アプリ
* サイト運営のための機能

こんな感じで、5つのコンテキストが、関連しあったシステム。

もしかしたら、採用企業側の採用関連システムとの連係も必要になるかもしれない。

コンテキストモデル


RDRA の基本ステップ。最初は、「システム価値」を明確にすること。

その中でも、第一歩は、コンテキスト図を描いて、「関連する人」「関連する外部システム」を洗い出して、関係者で共通理解にすること。

募集と採用は、密接に関係しているし、小規模な企業の採用であれば、募集情報をサイトに掲載する人と、それに対する応募に対応して、選考をする人は、同じ人(部門)。

ただ、この二つの業務は本質的に、別の業務。ここらへんの登場人物分けが、最初の検討テーマ。

あと「サイト運営」を、初期のコンテキストモデルでは、ひと固まりに「サイト運営者」にしちゃったけど、ここはかなり怪しい。

まあ、業務モデルくらいまで、落としながら、コンテキストモデルの見直し、特に登場人物の見直しを繰り返そう。

「リレーションシップ駆動」なので、コンテキスト図で把握した「登場人物」は、「要求モデル」のアクタ、「業務モデル」(アクティビティ図)のレーン、ユースケースモデルのアクタに、それぞれ、直接対応させるので、後続のモデリングをしながら、なんども、登場人物のとらえ方を改定することになる。

実践では、業務モデルのレーンと、コンテキストモデルのアクタが、ずれを発見。
どうやって整合させるか、今、検討中。

5つのサブの問題領域を、一つのコンテキストモデルでとりあえずは進めてみる。

要求モデル


コンテキストモデルと、アクタとシステム、外部システムとシステムとの間に引いた関連線をさらにブレークダウンしてみる。

線を引く、つまり、関連がある、という認識合わせは、コンテキストモデルのほうでやる。
それぞれの関連の意味(価値)を、具体的に考えてみるのが、要求モデル図。

ここの議論、整理の仕方は、たぶん、RDRAというか、上流工程のキモ。
教科書的な方法論を語っても、実践では、なかなかうまくいかなかった。
私流だけど、「大まかなユースケース」「重要なユースケース」という視点で、「中核機能の列挙」というような視点で、とりあえず進めている。

あと、でてきたニーズや要望は、とりあえずメモしておくべき。
ただし、これを、要求モデルに入れると、収拾がつかなくなるので、

* 中核な関心事(価値)の入れ物 (UMLの要求モデル図)
* それ以外の関心ごとの入れ物 (要望の箇条書きメモをノート形式で)

に使い分けて、その間を行ったりきたりしながら、整理をしている。

概念モデル


神崎さんの本来のやり方だと、概念モデルは、「システム価値を明らかにする」ための最初のステップではなく、次の「システムの外部環境を把握する」ステップでの作業。

私の「ドメイン駆動設計」こだわりで、「概念モデル」は、最初の「システム価値を明らかにする」モデルとして位置付けている。

というか、ドメインモデルの基本設計をやりながら、コンテキストモデル、要求モデルを発展させていく、「ドメイン駆動」でやっている感じ。

順番はともかく、「モデル間の関係、整合性のチェック」という神崎さんのRDRAの基本は、ちゃんと押さえてやっているつもり。ドメイン駆動だけど、リレーションシップの整合性には、とてもこだわている、ということ。

業務モデル


コンテキストで、登場人物を洗い出し、要求モデルで、システムに期待される、主要な関心事を明らかにし、それを、概念モデル(初期のドメインモデル)という形で、まず、だいたいのイメージをつかむ。

今日は、このイメージをもとに、次の「システムの外部環境を把握」するためのステップとして、「業務モデル」、いわゆる、業務フロー図を、描き初めてみた。

見事に、概念モデル、要求モデル、コンテキストモデルに立ち戻って、いろいろ改定することになった。
モデル間の関連性や整合性をいつも気にかける、これが、RDRA流なんだと思う。

アークテクチャ


並行して、アーキテクチャの設計も進めている。
要件を定義してから、アーキテクチャ、といのは、ちょっと遅すぎる感じ。
概念モデルといっても、最初から、ソフトウェアにするための作業なのだから、その概念を、どうやって実装するかの議論も並行して進めちゃうのが私流。

今のところ、主な技術ポイントは、こんな感じ。

Bean Validation の全面採用


Spring Framework 3.0 で、 JSR-303 のアノテーションベースの Bean Validation がサポートされた。
ドメインモデルの実装のための便利な実装技術。さっそく飛びついた。

今のところいい感じ。 ( Spring Web Flow で、ちょっと一工夫必要だけど、ここは、Spring Framework エキスパートの大野さんの、さくっと、かたをつけてもらえそう)

プロジェクトの分割とプロジェクト参照


システム全体のレイヤ構造、アプリケーション間の依存関係、ドメインモデル内部のドメインオブジェクト間の依存関係、...

概念的には、依存関係、参照関係を、すっきり整理し、可能な限り、単一方向で、必要最小限の依存関係にする。

設計レベルでは、パッケージ図でそれなりにきれい描ける。
でも、実装に入ると、結構、あちこちで、 好き勝手に参照を始める。
Public クラスと、Public メソッドであれば、結局、実装としては、どんな参照でも記述できてしまう。

なんのことはない、グローバル変数の悪夢、スパゲティコードアンチパターンへまっしぐら。

今回は、これを、概念レベルの設計や、お互いの設計モラル(?)に依存するのではなく、物理的に、制限をかける試みにチャレンジ。

まあ、大げさな話ではなく、 Eclipse のプロジェクトの分割と、プロジェクト参照の設定の決めごとの話。

レイヤ構造で、ちゃんと実装するために、レイヤごとに別プロジェクトにする。そして、下のレイヤのプロジェクトを、上のレイヤのプロジェクトが「プロジェクトで参照」する。

jar にして、ライブラリの参照にするのではなく、プロジェクトの参照にする。

こうすると、双方向の参照が実装しにくくなる。(やればできちゃう方法はある)

ドメインモデルを、依存関係を元に、プロジェクトを複数に分割することにした。
ドメイン駆動設計(DDD) の、ドメインのレイヤリングを参考にしてモデリング。

その結果を、プロジェクト分割として、実装する。

一つのドメインモデルプロジェクトにしてしまうと、意味的な依存関係を無視して、あるドメインオブジェクトは、ドメインモデル内の他の public な オブジェクト/メソッドを自由にアクセスできてしまう。

ドメインを意味のあるパッケージ単位にまとめ、パッケージの参照を、単一方向かつ最小限に設計する。

そのパッケージ単位に、Eclipse のプロジェクトにして、開発を進める。
プロジェクト参照にしておくことで、下のレイヤ(プロジェクト)のドメインオブジェクトは、上のレイヤ(プロジェクト)のドメインオブジェクトを参照できなくなる。

こうやって、依存関係をかなり厳しく制約することで、安定したドメインモデルの設計・実装ができると思っている。

この開発案件では、この方式にこだわってみようと思う。

実際には、パッケージレベルでは、双方向に参照したくなる、ケースもでてきそう。
その場合、その原因になっているドメインオブジェクトの再モデリング、設計の改善ネタを発見したということ。

まあ、双方向の参照を許したほうが、目先の設計・実装は簡単になることはわかっている。

でも、そこをがんばって、設計改善することが、グローバル変数の悪夢、スパゲティコードのアンチパターンから抜け出す、足がかりだと思う。

まあ、ここらへんも、やりながら、いろいろ設計・実装ノウハウをためていこうと思う。

コメント
コメントする









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