1月24日は当社の創立記念日でした。
当社の創立記念日は、全員でセレブになった気分。
フランス料理店でお祝いするのが常でした。
あの「シャトーレストラン ジョエル・ロブション」「トゥールダルジャン」「クィーンアリス」など、名店を次々に制覇したものでした。
そして、今回は、……あの「ミシュラン3つ星」の高級レストラン。
ではなくて、ミシュラン観光地に燦然と輝く「高尾山」に登山しました。
あいにく前日は雨でしたが、1,050円の弁当をキャンセルしたら申し訳ない。
雨天決行を強く誓ったアイロベックス社員に、天候は味方してくれたのでした。
というわけで今日も、まだ、脚が痛い。
当日飲んだ酒は抜けたが、筋肉痛は3日後にやってくるというわけです。
さて、前回ビジネスロジックとは、企業独自のロジックであると申し上げました。
追伸として、迂闊に
追伸：ビジネスロジックは、JAVA、VB.NET、PHPといった言語で表現されるよりもデータベース言語にしておく方が良いと思いますよ。
などと書いてしまい、きちんと説明しなかったため意味不明の文になってしまったことと思います。申し訳ありませんでした。
嬉しいことにこの件で先週、読者の方からお問い合わせをいただきました。まず、表現方法があまりにも悪かったことで誤解があったと思うので、今回は詳しく書きたいと思います。
例えば、システム開発を行う場合、プログラム言語を使って開発します。
これが、20年前であれば主流がCOBOL、現在であればJAVAやVB.NETという言語になっています。
大雑把にいうと、入力から出力に加工する。
つまり「inputからoutput」ということなのですが、画面から入力された情報をデータベースに保存して、そのデータを加工して出力するのがシステムというわけです。
そこで、情報を入力する画面を作るには、上記にご説明したプログラム言語を使って開発します。
しかし、画面から入力する、というその機能を実現するためには、ビジネスロジックには関係ない機能がいくつも必要になってくるわけです。
例を以下に挙げます。
・ 郵便番号が入力されたら、郵便番号辞書を検索して自動で住所を表示する。
・ 入力された住所が長すぎた場合、「長すぎて登録できない」というエラーメッセージを表示する。
・ 金額欄に数字以外の文字が入力されないようにする。
以上のような機能です。
このような画面制御の機能も実はプログラム言語を用いて作っているのです。
システム開発の1つの方法としてすべての機能、つまりビジネスロジックも画面制御もすべて同一言語で作るという方法が行われます。
特に、機能数が少ないシステムの場合はこの方法が多いようです。
しかし、1つの言語のみで全ての機能を作るといった場合に問題が起こります。
1)どこがビジネスロジックで、どの部分が「画面制御」なのか、プログラムを読んで切り分けしにくい。
ドキュメントがあったとしても、多くの機能の中にビジネスロジックが埋没してしまいやすい。
2)新しいシステムを作るごとに同じビジネスロジックが、違った場所に作りこまれてしまう。
これは、そのビジネスロジックに変更が起きた場合に、修正しきれない、ミスが起きるという問題も含みます。
そこで、JAVAやVB.NETといったプログラム言語ではなく、SQL ServerやORACLEのストアドプロシジャといったデータベース言語（個別では、Transact SQLとか、PL/SQL等という名前がついています）にビジネスロジックを書くのです。
データベース言語の良い点は何か。
今後もリレーショナルデータベース（RDB）は、プログラム言語よりも長く残っていくものだと考えられます。
JAVAやVB.NETだといったプログラム言語が変わっても、データベースを変えるのはまず無いでしょう。
Webシステムだろうが、クライアントサーバーシステム方式のシステムだろうが、データベースを使うことでこのデータベース言語で作ったビジネスモデルを呼び出せます。
10年くらい昔は、この方式でシステム開発することを、3-Tier（スリーティア）開発などと呼んでいました。
Webだろうが、クライアントサーバーシステムだろうが、大規模だろうが小規模だろうがそこにビジネスロジックがある限り、他の機能との切り分けが必要であるかぎり3-Tier開発は、今でも有効です。
説明がまたまた長くなってしまいました。
ビジネスロジックをデータベース言語で作成すべきというのは、RDBのストアドプロシジャで作るべきだという考えなのがおわかりいただけましたでしょうか。
Vol.00177