« 「要件定義」に何週間もかける? | トップページ | ナチュラルキーを主キーにしてはいけない »

2011.07.04

「個性的な機能」の病理

 業務システムに、無駄に個性的な機能は要らない。ここで言う「個性的な機能」は「動きもコードも独特な機能」のことで、そのような機能は保守コストが余分にかかる。それがほんとうに必要な個性であれば問題はないのだが、「無駄に個性的」な機能がバイ菌のように繁殖しやすい。

 なぜ無駄に個性的な機能が増えるのだろう。原因は少なくとも2つある。

 まず、データ処理の対象であるDBの構造が無駄に個性的、つまり正規化されていないゆえである。もちろんどんなシステムも個性的なDB構造をとるものだが、正規化の過程を通じてその個性は「単純な位相の組み合わせ」として形式化されるべきだ。形式化されていないDB構造を処理するデータ処理機能は、いちいち個性的にならざるを得ないからだ。以前のエントリーでも触れたが、システムを刷新するときにDB構造を見直すことをしないばかりに、機能が際限なく無駄な個性を帯びてゆく事例が後を絶たない。

 無駄に個性的な機能が増殖する2つ目の理由は「ビジネスロジックの配置」に関係している。ビジネスロジックとはデータ処理にともなうさまざまな仕様要素のことで、「仮想フィールドの設定」、「入力値の妥当性検査」、「関連テーブルの操作」等に分類できる。これらが「機能の仕様」として配置されると、機能はいちいち個性的なものとなる。しかし、その多くは「テーブルの拡張仕様」として配置転換可能なものだ。

 たとえば、「入荷実績エントリー」の機能を用いて入荷明細テーブル上に入荷数と仕入単価を登録することで、仕入計上が起こるとする。この場合、仕入実績レコードが書き出されるロジックも、これにともなって買掛残高が更新されるロジックも「入荷実績エントリー」の機能上の仕様と考える必要は必ずしもない。入荷明細が一定の条件にしたがって更新されたときに実行されるはずの「入荷明細テーブルの拡張仕様」とみなしても間違いではない。それが「入荷実績エントリー」の仕様にしか見えないとしたら、この仕様を起動する機能がたまたま1本しかないゆえの錯覚にすぎない。

 ここまで原因がわかれば、業務システムから無駄な個性を脱臭させる方法も明確だ。まずはDBを正規化する。そのうえで、ビジネスロジックを機能から引き剥がしてDB側に移行すればよい。結果的に、個々のデータ処理機能は「うすっぺらでありきたり」な存在になる。

 そうなればしめたもので、自動生成なり動的制御なりの合理化技術を活用して、必要な機能群をサクッと作ってしまえる。かくして開発者の仕事の中心が「個性的な機能のプログラミング」から「ビジネスロジックの確立と維持」に移る。定時になったらとっととタイムカードを押して、個性的な人生を楽しもう。「無駄に個性的な機能の山」にかけがえのない人生を損なわれてはたまらない。

関連記事:
「DB構造を見直さない」というアンチパターン
開発効率化のための基本戦略「類型化」


※お知らせ
2011/07/08(金)の関西IT勉強会
渡辺幸三さんに教わる「DOAの基本をおさらいしようの会 」
で、ビールを飲みつつデータベース設計の基礎を解説します。ビールを飲みつつ楽しく学びましょう。

|

« 「要件定義」に何週間もかける? | トップページ | ナチュラルキーを主キーにしてはいけない »

コメント

大変面白く読ませていただいております。
1点質問させてください。
「テーブルの拡張仕様」
とは具体的にどう実装されるものを指しておられるでしょうか?

トリガーもしくはDB更新機能(ストアドやデータアクセス用の共通処理)に配置されるものでしょうか?

「データの整合性・一貫性に関するロジックはデータ層に近いところに集約しよう」
といったところでしょうか?

投稿: SE1 | 2011.08.31 14:33

理解されているところに間違いはありません。

ただ、私はトリガーやストアドでビジネスルールを記述する気にはなりません。また、ビジネスルールをかかえたテーブルに対応するクラスを作ってセッションと通信させようとも思いません。

いっぽう私が自作した環境では、専用エディタで仕様を眺める限り、ビジネスルールはテーブル定義の一部であるように見えます。しかしアプリを起動すると、それらはプログラムの仕様として動的に組み込まれます。

大事なことは、仕様情報を眺めたときに、ビジネスルールが「あたかもテーブル仕様の一部として見える」ような開発環境を用意する点だと思います。「仕様の見え方」の問題であって実装の問題ではないという感じがあるんですよね。

投稿: 渡辺 | 2011.09.01 09:44

ご説明いただきありがとうございます。

システム全体を貫く共通仕様として「テーブル拡張仕様」のような概念でロジックを共有することは仕様の簡潔化の観点で大変効果的に思います。

一方で効果的な実装方法はなかなか難しい問題ですね。
専用エディタでサポート、というのは斬新で参考になりました。

システム開発環境を一つに寄せられないという制約がある場合はストアドやサービスAPI化という方向で実現することになるのでしょうね。

テーブル拡張仕様の考え方が難しくなるのは例外ケースが発生したときでしょうか。例外ケースに対して拡張仕様を適用しない、などの状況が発生したときに枠組みをどのように維持するのか、また一部壊すのか、そこらへんに興味があります。

※専用エディタ使ってみてください!ということになりますね(^ω^)

投稿: SE1 | 2011.09.05 18:43

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 「個性的な機能」の病理:

« 「要件定義」に何週間もかける? | トップページ | ナチュラルキーを主キーにしてはいけない »