採用支援業務の「選考状況」の管理を分析している。
RDRA(リレーションシップ駆動分析)のプロトコルモデル(ステートマシン図)と、イベントモデル(イベント図)を使いながら、だいぶ、分析レベルのモデルとして骨格がはっきりしてきた。
業務の主要な関心ごとが、「状態」の視点と、「アクションイベント(状態遷移のトリガー)」の視点から、立体的なモデルになってきた。
この「状態(state)」と「イベント」のモデルを、「イベントソーシング」スタイルで、実装する設計を始めてみた。
初期の設計モデルは、こんな感じ。
UIから、わたされた、採用担当者のアクションを、サービス層の「選考アクションサービス」クラスが、処理する。
サービス層のクラスは、ファサードにして、実際のビジネスロジックは、ドメイン層の、
・選考プロシジャ (業務ルール)
・選考状況リポジトリ (記録)
・選考メッセージング (通知)
3つのクラスに委譲する。
業務のオペレーション、つまり「起きたこと」は、 「選考アクション」イベントオブジェクトで表現する。
ファウラーの Domain Event パターンをそのまま使っている。
イベントオブジェクトは、イベントタイプオブジェクト(選考アクションタイプ)と、サブジェクト(関心ごと)である「選考コンテキストの現在の状態」を参照する。
選考アクションサービスは、採用管理者が指示した「候補者」をキーにして、「現在の選考状況」を取りだす。
「コンテキスト」パターンにしているのは、選考履歴とか、選考の関係者とか、選考書類とか、その他のさまざまな情報の参照ポイントにするため。
「選考状況」をユーザに戻す(画面に表示する)時に、「選考プロシージャ」オブジェクトに、「選択可能なアクション」を問い合わせる。
状況ごとに、可能なアクションは、異なる。「選択可能なアクションリスト」を、画面では、「アクションメニュー」として、表現する。
ユーザがあるアクションを選択すると、再び、「選考プロシージャ」オブジェクトに問い合わせて、そのアクションのタイプを実行するための「ひな型(プロトタイプ)」として「選考アクション」オブジェクトを作成する。
選考理由とか、選考結果とか、必要な情報を入力するためのオブジェクト。
画面のフォームにマッピングして表示。
ユーザの入力内容はオブジェクトにバインドした結果を、「選考アクションサービ」が受け取る。
「選考アクションサービス」は、「選考プロシージャ」オブジェクトに、アクションの妥当性検証と、ドメインオブジェクトの現在の状況の変更とか、履歴への追加とか、さまざまな反映処理を、「委譲」する。
検証&反映が、無事に終わったら、「記録」すべきこと、「通知」すべきことの「業務のルール」を、「選考プロシージャ」オブジェクトの問い合わせる。
問い合わせ結果に応じて、リポジトリクラス(永続化インタフェース)を使って、適切に記録。
メッセージングクラス(通知インタフェース)を使って、しかるべき相手に、「変更が起きたこと」あるいは「処理が終わったこと」を通知。
「選考プロシージャ」オブジェクトが、「選考業務」の知識を表現している。
その知識の表現手段として、列挙型の「状況タイプ」「アクションタイプ」を用意する。
この設計で、変更が容易に安全にできるかの検討がもうちょっと必要。
・状況をもっと、細かく管理したくなった場合になにが起きるか?
・現在は許可している遷移を、不許可にする場合、なにが起きるか?
・許可していない遷移を追加した場合は?
・永続化した過去の選考履歴と、変更後の整合性は?
・ユーザの画面操作だけでなく、REST スタイルの API や、非同期メッセージング用のサービスとして、そのまま使えるか?
...
まあ、初期のモデルなので、実装を進めながら、ここらへんに対応できる、しっかりした設計・実装に育てていければと思う。
今のところ、足がかりモデルとしては、悪くないと思っている。
RDRA(リレーションシップ駆動分析)のプロトコルモデル(ステートマシン図)と、イベントモデル(イベント図)を使いながら、だいぶ、分析レベルのモデルとして骨格がはっきりしてきた。
業務の主要な関心ごとが、「状態」の視点と、「アクションイベント(状態遷移のトリガー)」の視点から、立体的なモデルになってきた。
この「状態(state)」と「イベント」のモデルを、「イベントソーシング」スタイルで、実装する設計を始めてみた。
初期の設計モデルは、こんな感じ。
構造
UIから、わたされた、採用担当者のアクションを、サービス層の「選考アクションサービス」クラスが、処理する。
サービス層のクラスは、ファサードにして、実際のビジネスロジックは、ドメイン層の、
・選考プロシジャ (業務ルール)
・選考状況リポジトリ (記録)
・選考メッセージング (通知)
3つのクラスに委譲する。
業務のオペレーション、つまり「起きたこと」は、 「選考アクション」イベントオブジェクトで表現する。
ファウラーの Domain Event パターンをそのまま使っている。
イベントオブジェクトは、イベントタイプオブジェクト(選考アクションタイプ)と、サブジェクト(関心ごと)である「選考コンテキストの現在の状態」を参照する。
振る舞い
選考アクションサービスは、採用管理者が指示した「候補者」をキーにして、「現在の選考状況」を取りだす。
「コンテキスト」パターンにしているのは、選考履歴とか、選考の関係者とか、選考書類とか、その他のさまざまな情報の参照ポイントにするため。
「選考状況」をユーザに戻す(画面に表示する)時に、「選考プロシージャ」オブジェクトに、「選択可能なアクション」を問い合わせる。
状況ごとに、可能なアクションは、異なる。「選択可能なアクションリスト」を、画面では、「アクションメニュー」として、表現する。
ユーザがあるアクションを選択すると、再び、「選考プロシージャ」オブジェクトに問い合わせて、そのアクションのタイプを実行するための「ひな型(プロトタイプ)」として「選考アクション」オブジェクトを作成する。
選考理由とか、選考結果とか、必要な情報を入力するためのオブジェクト。
画面のフォームにマッピングして表示。
ユーザの入力内容はオブジェクトにバインドした結果を、「選考アクションサービ」が受け取る。
「選考アクションサービス」は、「選考プロシージャ」オブジェクトに、アクションの妥当性検証と、ドメインオブジェクトの現在の状況の変更とか、履歴への追加とか、さまざまな反映処理を、「委譲」する。
検証&反映が、無事に終わったら、「記録」すべきこと、「通知」すべきことの「業務のルール」を、「選考プロシージャ」オブジェクトの問い合わせる。
問い合わせ結果に応じて、リポジトリクラス(永続化インタフェース)を使って、適切に記録。
メッセージングクラス(通知インタフェース)を使って、しかるべき相手に、「変更が起きたこと」あるいは「処理が終わったこと」を通知。
検討課題
「選考プロシージャ」オブジェクトが、「選考業務」の知識を表現している。
その知識の表現手段として、列挙型の「状況タイプ」「アクションタイプ」を用意する。
この設計で、変更が容易に安全にできるかの検討がもうちょっと必要。
・状況をもっと、細かく管理したくなった場合になにが起きるか?
・現在は許可している遷移を、不許可にする場合、なにが起きるか?
・許可していない遷移を追加した場合は?
・永続化した過去の選考履歴と、変更後の整合性は?
・ユーザの画面操作だけでなく、REST スタイルの API や、非同期メッセージング用のサービスとして、そのまま使えるか?
...
まあ、初期のモデルなので、実装を進めながら、ここらへんに対応できる、しっかりした設計・実装に育てていければと思う。
今のところ、足がかりモデルとしては、悪くないと思っている。