ビジネスイベント系テーブルの初期モデル
UMLのアクティビティ図とか業務フロー図で、業務のステップを洗い出す。
受注→出荷→請求→回収(入金)
一つ一つのステップが、ビジネスイベントそのもだから、それぞれ、テーブルにして記録すればよい。
主キーと外部キー
主キーは、受注番号などの自然キーではなく、システムで生成するサロゲートキー(代替キー)を使う。前回説明したように、受注変更の場合は、同じ受注番号で、別のレコードを作成するので、受注番号は、主キーにできない(しない)。
外部キーは、先行するイベントの主キーを参照する。
後続するイベントへの外部キーは先行イベント側に作成しないこと。ビジネスイベントの発生時点では、後続イベントの情報は存在しない。発生時点で存在しない情報は、記録できない。するべきではない。
イベントの発生順で外部キーを実装して、参照制約を宣言しておく。
ビジネスイベント系テーブルは What Who When
ビジネスイベントの記録は、What Who When が基本3点セット。
受注レコードの例:
What : 何を受注したか
Who1 : 誰から受注したか
Who2 : 誰が受注したか
Who3 : 誰が記録したか
When1: いつ受注したか
when2: いつ記録したか
3点セットといいながら、実は、6点セット。
ビジネスの記録は、行為者(誰が受注したか)と記録者(レコード作成者)は、別に管理したほうが実践的です。
When も、ビジネス上の受注日と、レコードを作成した日時は別に持つほうが良い。
ビジネスイベントが実際に発生した日時とデータベースに記録した日時は、通常は一致しません。
備考欄は別テーブル
ビジネスイベントの記録に備考欄や摘要欄を設けて、テキストを入力可能にすることも多い。
このテキスト情報は、別テーブルにして、受注レコードへの外部キーを持つべきです。イベントテーブルは、あくまでも、必ず記録できる、NOT NULL 制約のカラムだけで構成する。
イベントテーブルと備考欄テーブルに分けるのも、役割を単純化したテーブルを作る、というテーブル設計の原則の適用例です。関心の分離です。
イベントの基本情報だけで十分な業務と、備考欄にも関心がある業務は通常は別です。備考欄の内容によって発生する業務は、例外系の業務になることが多い。この例外系の業務用にシステム機能を設計・開発するときに、関心を分離したテーブルになっていることのメリットがでてきます。
Core Domain or Generic Subdomains ?
ビジネスイベントのテーブルは、Domain-Driven Design の Responsibility Layers の Operation Layer の永続化の実装パターンです。
Operation Layer (業務の層)であるビジネスイベントのモデリングやテーブル設計は、ビジネスアプリケーションの基本部分です。業務システムであれば、必ず、なんらかの実装が必要です。
この領域を「基幹システム」と呼ぶことがある。ただし、この部分は、業務システムにとって、必須ですが、中核( Core Domain ) とは限りません。そのビジネスにとって、競合との差別化のポイントや競争力の源泉こそが Core Domain としてモデリングと設計の重点になります。
私は、ビジネスイベント系のモデリングとテーブル実装は、ほとんど場合、Generic Subdomains だと思います。つまり、世の中に良いものがあれば、それを流用して活用する。最も優秀な人材は、この領域ではなく、もっと本質的な課題を担当させるべきでしょう。
既存のモノを利用する場合、パッケージソフトという選択肢があります。私は、それよりも、書籍で公開されている、汎用モデルを流用することが多い。
・データモデルリソースブック
・データモデルパターンズ
・アナリシスパターン
パッケージソフトにせよ、公開モデルの流用にせよ、それを評価して、採用方針を決めるのは、もちろん、経験豊富で優秀な技術者が判断する。ただし、具体的な設計や実装は、そこそこの技術者にまかせる。あまり凝った設計をやりすぎないようにリードしてやる。
イレギュラーな処理のモデリング
ビジネスイベント系のモデリングをするために、現場でヒアリングをすると、さまざまなイレギュラーな処理や「特別の」やり方がいろいろでてくる。
そして、その「特別な処理」こそ、差別化の要因、競争優位の源泉と考えている人も多い。
ここの見極め、利害関係者での方針の共有は、重要な問題です。
私は、たいていの場合は「特別の処理」は、業務のムリ・ムラ・ムダであり、もっとシンプルにすることが、ビジネスの成功要因だと思います。そこを整理して、エネルギーをもっとほかの場所に向けることが成功要因になる。
ただ、競合との差別化を徹底した「特別の処理」で実現する、という道もあると思います。その方針が経営ビジョンから、日々のオペレーションレベルまで一貫して実施されるなら、すばらしい戦略になる可能性がある。
前者であれば、ビジネスイベント系のモデリングは、Generic Subdomains であり、既存のモデルやパッケージの活用を重視する。
後者であれば、Core Domain であり、優秀なメンバーを投入して「特別な処理」を効果的に進めることができる、オペレーションのモデリングを行い、システムの設計と実装を行う。
典型的なアンチパターンは、方針は、前者なのに、モデリングと設計は、後者、というパターンです。
Core Domain でない領域に、優秀な人材を投入して、時間とエネルギーを浪費する。
UMLのアクティビティ図とか業務フロー図で、業務のステップを洗い出す。
受注→出荷→請求→回収(入金)
一つ一つのステップが、ビジネスイベントそのもだから、それぞれ、テーブルにして記録すればよい。
私の場合は、ER図でビジネスイベントの発生順に左から右にイベント系のテーブルを並べる。つまり、ER図がビジネスプロセス図にもなっている。
主キーと外部キー
主キーは、受注番号などの自然キーではなく、システムで生成するサロゲートキー(代替キー)を使う。前回説明したように、受注変更の場合は、同じ受注番号で、別のレコードを作成するので、受注番号は、主キーにできない(しない)。
外部キーは、先行するイベントの主キーを参照する。
後続するイベントへの外部キーは先行イベント側に作成しないこと。ビジネスイベントの発生時点では、後続イベントの情報は存在しない。発生時点で存在しない情報は、記録できない。するべきではない。
イベントの発生順で外部キーを実装して、参照制約を宣言しておく。
ビジネスイベント系テーブルは What Who When
ビジネスイベントの記録は、What Who When が基本3点セット。
受注レコードの例:
What : 何を受注したか
Who1 : 誰から受注したか
Who2 : 誰が受注したか
Who3 : 誰が記録したか
When1: いつ受注したか
when2: いつ記録したか
3点セットといいながら、実は、6点セット。
ビジネスの記録は、行為者(誰が受注したか)と記録者(レコード作成者)は、別に管理したほうが実践的です。
When も、ビジネス上の受注日と、レコードを作成した日時は別に持つほうが良い。
ビジネスイベントが実際に発生した日時とデータベースに記録した日時は、通常は一致しません。
備考欄は別テーブル
ビジネスイベントの記録に備考欄や摘要欄を設けて、テキストを入力可能にすることも多い。
このテキスト情報は、別テーブルにして、受注レコードへの外部キーを持つべきです。イベントテーブルは、あくまでも、必ず記録できる、NOT NULL 制約のカラムだけで構成する。
イベントテーブルと備考欄テーブルに分けるのも、役割を単純化したテーブルを作る、というテーブル設計の原則の適用例です。関心の分離です。
イベントの基本情報だけで十分な業務と、備考欄にも関心がある業務は通常は別です。備考欄の内容によって発生する業務は、例外系の業務になることが多い。この例外系の業務用にシステム機能を設計・開発するときに、関心を分離したテーブルになっていることのメリットがでてきます。
Core Domain or Generic Subdomains ?
ビジネスイベントのテーブルは、Domain-Driven Design の Responsibility Layers の Operation Layer の永続化の実装パターンです。
Operation Layer (業務の層)であるビジネスイベントのモデリングやテーブル設計は、ビジネスアプリケーションの基本部分です。業務システムであれば、必ず、なんらかの実装が必要です。
この領域を「基幹システム」と呼ぶことがある。ただし、この部分は、業務システムにとって、必須ですが、中核( Core Domain ) とは限りません。そのビジネスにとって、競合との差別化のポイントや競争力の源泉こそが Core Domain としてモデリングと設計の重点になります。
私は、ビジネスイベント系のモデリングとテーブル実装は、ほとんど場合、Generic Subdomains だと思います。つまり、世の中に良いものがあれば、それを流用して活用する。最も優秀な人材は、この領域ではなく、もっと本質的な課題を担当させるべきでしょう。
既存のモノを利用する場合、パッケージソフトという選択肢があります。私は、それよりも、書籍で公開されている、汎用モデルを流用することが多い。
・データモデルリソースブック
・データモデルパターンズ
・アナリシスパターン
パッケージソフトにせよ、公開モデルの流用にせよ、それを評価して、採用方針を決めるのは、もちろん、経験豊富で優秀な技術者が判断する。ただし、具体的な設計や実装は、そこそこの技術者にまかせる。あまり凝った設計をやりすぎないようにリードしてやる。
イレギュラーな処理のモデリング
ビジネスイベント系のモデリングをするために、現場でヒアリングをすると、さまざまなイレギュラーな処理や「特別の」やり方がいろいろでてくる。
そして、その「特別な処理」こそ、差別化の要因、競争優位の源泉と考えている人も多い。
ここの見極め、利害関係者での方針の共有は、重要な問題です。
私は、たいていの場合は「特別の処理」は、業務のムリ・ムラ・ムダであり、もっとシンプルにすることが、ビジネスの成功要因だと思います。そこを整理して、エネルギーをもっとほかの場所に向けることが成功要因になる。
ただ、競合との差別化を徹底した「特別の処理」で実現する、という道もあると思います。その方針が経営ビジョンから、日々のオペレーションレベルまで一貫して実施されるなら、すばらしい戦略になる可能性がある。
前者であれば、ビジネスイベント系のモデリングは、Generic Subdomains であり、既存のモデルやパッケージの活用を重視する。
後者であれば、Core Domain であり、優秀なメンバーを投入して「特別な処理」を効果的に進めることができる、オペレーションのモデリングを行い、システムの設計と実装を行う。
典型的なアンチパターンは、方針は、前者なのに、モデリングと設計は、後者、というパターンです。
Core Domain でない領域に、優秀な人材を投入して、時間とエネルギーを浪費する。