特定の顧客用に特別なビジネスロジックを用意している場合、以下のようにソースコード中に顧客情報を記述することで実装することはできます。
（顧客番号が’1111111’である場合に特別なビジネスロジックを実行するとします）
：
：
：
if (処理中の顧客番号が'1111111'の場合) {
特別なビジネスロジック
}
：
：
：しかし、この実装方法には以下の問題があり、望ましくありません。
特別なビジネスロジックを適用する対象の顧客の情報は、（データの管理にDBを使用しているシステムであれば）DBに持たせるべきです。
・頻繁なソースコード修正が必要になる
対象となる顧客が追加されたり削除されたりする度にソースコード修正が必要になる。
コンパイルやデプロイも必要となり、対応工数や対応のリスクが増加する。
→DBで管理すればDB内の情報の補正だけで済む。
・データを一元管理できなくなる
対象となる顧客を調べるためにはソースコードを見なくてはならなくなる。
→DBで一元管理すれば情報の検索が容易になる。
・セキュリティを確保するのが難しくなる
ソースコードが流出した場合に顧客情報も同時に流出してしまう。
→DBで一元管理すれば、顧客情報の流出のリスクを減らすことができる。
対象となる顧客の情報をDBに持たせる場合、以下のような実装になります。
１．特定処理対象顧客テーブルを別途作る場合
※特定処理対象顧客テーブルには、特定処理の対象となる顧客番号を格納する。
：
：
：
if (特定処理対象顧客テーブルに処理中の顧客番号が存在する場合) {
特別なビジネスロジック
}
：
：
：２．既存のテーブルにフラグを持たせる場合
※「特定処理対象フラグ」のカラムを追加し、処理対象なら’1’、処理対象外なら’0’をセットする。
：
：
：
if (処理中の顧客番号について顧客テーブル.特定処理対象フラグが'1'の場合) {
特別なビジネスロジック
}
：
：
：
いかがでしたでしょうか。
ソースコード中に顧客情報を記述してしまい保守性が低下するという話は良く聞きますし、私自身もそのようなソースを保守開発して苦労したことがあります。
また、最近ではソースコードと共に顧客情報が流出したという事故もニュースになっています。
そのような背景があり、今回の記事を書いてみました。
顧客情報が記述されたソースコードを目にする機会は珍しくないと思いますが、それはアンチパターンであるというのは認識しておくべきでしょう。
コメント