そごうソフトウェア研究所

SOA、開発プロセス、ITアーキテクチャなどについて書いています。Twitterやってます@rsogo

SOAとデータベース(3)

mark-wadaさんのエントリ「ビジネスプロセスパターン研究〜SOA時代のデータ管理〜」では、データをリソース系データとイベント系データにデータを分類されています。

ここではデータを次の3種類に分類してみようと思います。便宜上、この分類を「所有者別データ分類」と呼びます。

1.プロセスだけが使うもの
2.個別システムだけが使うもの
3.複数のシステムで共有して使われるもの


プロセスもひとつのシステムと考えれば、1と2は同じとも考えられますが、ここでは複数のシステムを横断する役目に着目して、別に分けて進みます。


この分類はリソース/イベント分類と直交させることができるので、表にするとこんな感じ。

所有者別データ分類 リソース系 イベント系
プロセスのデータ プロセス種別、ステータス種別 インスタンスID*1とそのステータス*2
個別システム固有のデータ パッケージの内部データベースの商品マスタ まあいろいろあるよね
共通データ 商品マスタとか取引先マスタとか 受注システムから生産システムに渡される発注データとか


上から見ていくと、、
プロセスのデータに関しては、ちょっと迷いますが、業務間で共通化しなくていいと考えました。理由としてはプロセスのデータはプロセスだけが更新したいからです。例えばフローの進捗を管理するテーブルは、個別システムが処理完了をもって更新するのではなく、プロセスが個別システムから結果もらって、プロセスがステータスを遷移させることで整理したい。



個別システム固有のデータは前のエントリで書いたとおり、機能とデータの凝集度という観点から共通化はしません。これにより個別システム間の結合度は下がります。そもそもパッケージの内部DBとか触れないですし。
ただし、システム固有データの中にも共通データのリソース系と重複するものがある可能性は高いので、その場合は共通データとの配布・同期をする必要がありそうです。


共通データのリソース系は仮想的か物理的かはあるとして、統合していくのがmark-wadaさんも言っておられるとおり良さそうです。
問題は共通データのイベント系データです。これは共通というか、あるシステムの結果が次のシステムの入力になっているようなものと考えています。この受け渡しとして2つのやり方を検討しました。

一つはプロセスが全て管理する形です。プロセスがあるシステムの入力を受け取り、次のシステムに渡します。データが大きくなってきた場合に、ちょっと心配です。後は個別システムのインターフェイスの変更にどのくらい依存しない作りにプロセスができるかってところでしょうか。


もう一つは、プロセスが管理するのはトランザクションを識別するデータのみです。例えば、受付IDとか帳票IDとか。それらに加えてバージョンだとか、枝番とか業務種別IDなんかも必要であれば。それ以外の実際の業務的なデータはDBなどを介して渡します。大量データにも対応できますが、業務アプリがある程度自由に改修できる状態でないと難しいですね。

*1:プロセスが起動する度に一意にふられるIDとします

*2:プロセスがいまどの状態か、つまり業務フローのどこにいるのか