KAI_REPORT

分割と階層化の限界

業務系アプリケーションが対象とするビジネスの現場を見ると、その業界毎に、会社毎に、驚くほど多様な取引形態があって、これを顧客情報、商品情報、受注情報と言った情報ベースで整理しようとしても一筋縄では行きません。

顧客情報一つを取っても、例えば顧客住所は、受注担当者から見れば商品のお届け先であり、請求担当者から見れば請求書の送付先になり、プロモーション担当者から見ればDMの送付先になると言う具合に、それぞれの担当者（業務機能）から見て同じ住所でも全く異なる目的があります。

これをもちろん目的別に分けることもできますが、そうなると、業務機能が追加される度に冗長な情報が増えていくことになります。

これが何を意味しているかと言うと、情報と業務機能の関係がリニア（線形）になっておらず、かつ、関係自体「疎」の関係であると言うことです。関係がリニアでないというのは、情報（データ）と業務機能が１対１に対応していないと言うことです。「疎」の関係とは、例え１対１の関係が成立していても、新しい業務機能が追加されると、今までの関係が簡単に解消ないし集約されると言うことです。

こう言った業務系アプリケーションが対象とする問題領域の特性を前提に、アプリケーションを設計、構築するための「アーキテクチャ」をテーマに、しばらく論じたいと思います。

更にもう一つ前提があります。

これから取り上げる問題領域とは、すでにコンピュータによってシステム化が行われている世界であり、手作業をアプリケーション化することは「想定外＾＾」です。この問題については以前のエントリーに書いた通り、ハブシステムによるスイッチを含めて別のノウハウが必要です。　KAI