実行可能な仕様書は“設計できるプログラマ”が書く：“実行可能な仕様書”を作る！（2）（2/3 ページ）

[渡辺 幸三，＠IT]

ビジネスロジックとは何か

　さて、データを表示させるだけの機能であれば問題になりにくいが、更新系機能までを考えた場合、「ビジネスロジック」の問題を無視できなくなる。それを仕様としてどこに配置するかは、システムの保守性や可読性に関わる大きな問題だ。

　この「ビジネスロジック」とは、「テーブル操作に伴うさまざまなルール」のことを言う。「業務上のルール」の意味から「ビジネスルール」とも呼ばれ、ざっと図5のように分類できる。「配置問題」を考える前に、ビジネスロジックが具体的にどのようなものを指すのか、簡単に説明しておこう。

図5　さまざまなビジネスロジック

　まず「仮想フィールドの設定」とは、例えば、受注テーブル上に「受注数量」と「受注単価」がある場合、それを掛け合わせた値である「受注金額」などを指す。つまり、仮想フィールド（導出属性や論理フィールドともいう）とは、テーブル上に物理的に存在するもの（物理フィールド）ではなく、「テーブル操作の過程で一時的に現れる変数」である。その設定ロジックがビジネスロジックの一種だ。

　「入力値の妥当性検査」とは、パネルからユーザーが入力した値が適正かどうかをチェックする過程のことである。「入力値がどのようであればエラーとみなされ、その際にどんなエラーメッセージを表示するかといった仕様」もビジネスロジックの一種だ。また、ある種の入力項目は条件によっては入力が禁止されなければいけないが、これも広い意味の妥当検査としてビジネスロジックの一種に含まれる。

　「関連テーブルの操作」とは、「テーブル操作に伴って実行されるべきテーブル操作に関する仕様」のこと。例えば、仕入振替報告がなされた場合、仕入実績レコードを新規追加するとともに、対応する買掛残高テーブルを更新する必要がある。仕入振替が修正されたなら赤黒訂正も必要だ。これらの一連の処理もビジネスロジックである。

　なお、これまでデータベースを正規化する過程で、機能の多くが「機能パターン」に収まると説明してきたが、「パターンに収まる仕様」も元はと言えば、上記の「関連テーブルの操作」に分類されるビジネスロジックである。つまり、アプリケーションドライバは、データベースの正規化を進めることで相当量のビジネスロジックを機能パターンに回収し、それらの扱いコストを大幅軽減するための技術である。

ビジネスロジックをどこに置くか

　では、多岐にわたるビジネスロジックは、仕様としてどこに「配置」されるのだろう。普通に考えたら「機能」の中ということになろうが、全てがそうなるわけではない。

　例えば、前述の「受注金額」の設定ロジックは、この項目がどの機能で利用されようと一律である。つまりそれは「機能定義の一部」ではなく、「テーブルの拡張定義」として位置付け可能なものだ。むしろこれを機能定義の一部として位置付けてしまうと、同じロジックがシステムのあちこちにダブって記述されることになる。

　「妥当性検査」についてはどうか。あるフィールドがどんなロジックで妥当性検査されるべきかは、多くの場合、そのフィールドが含まれるテーブルに固有の仕様である。機能上の仕様のように見えるとしたら、それは単にそのフィールドの値を保守するための機能がたまたま1本しかないための錯覚にすぎない。

　「関連テーブルの操作」についても同様だ。出荷実績報告がなされた場合に起こる関連テーブルへの操作は、「出荷実績テーブルの拡張定義」とみなせる。これが機能上の仕様のように見えるのは、単に出荷実績報告を実行する機能がたまたま1本しかないためだ。

　要するに「機能定義の中」から「テーブル定義の中」に移行できるビジネスロジックは、実は想像以上に多いということだ。

図6　「機能定義の中」から「テーブル定義の中」に移行できるビジネスロジックは、実は想像以上に多い

ビジネスロジックをいかに記述するか

　では、テーブル定義上に配置可能なビジネスロジックがあるとすれば、それをどんな様式を用いて記述すれば良いのだろう。機能パターンごとの仕様情報が様式化できたように、ビジネスロジックも「パターン」を想定して様式化できるものだろうか。それは不可能ではないにせよ、実は労多くして実りが少ない。

　例えば、あるテーブル上の日付項目Aの入力値について、「別の日付項目Bよりも未来でなければいけない」という妥当性検査ロジックがあるとする。この種のロジックを取り込むために「ビジネスロジックパターン」なるものの1つとして「日付チェックに基づく妥当性検査」を想定して様式化したとしよう。

　だが、比較相手の日付項目Bの値を手に入れるために、複雑なテーブル操作が必要だとしたらどうだろう。さらに他の項目CやDの値によってもIF文で条件付けられているとしたら、単純な「日付チェック」の様式では扱いにくい。

　実際、ビジネスロジックの内容は多岐にわたり、パターンを逸脱する例がいくらでも出てくる。それが現実の業務システムというものだ。それゆえに、ビジネスロジックを事前に類型化してそれぞれに様式を用意しておくやり方は有効とは言いがたい。

　ビジネスロジックを「テーブルトリガー」や「ストアドプロシージャ」といった機能を使って記述する方法もある。しかし、このやり方にはいくつか問題がある。まず、利用できる言語が通常のプログラミング言語に比べて記述能力に劣る。また、それらの機構はDBMS固有の形式を持っているために、特定DBMSへのロックインが起こりやすいという問題もある。

　ではどうすればいいのか。実はいい方法がある。スクリプト言語を使ってビジネスロジックを記述すればいい。そのための技術を、われわれはすでに手にしている。Rhino（ライノー）である。