外部インタフェースのコードと内部実装のためのコードを分離する

by tanabe on July 19, 2006

10年来の業務プログラムなので、いろいろ経緯があって今の形なのは仕方がないと思うけど、よくない設計に何も言わないとそのまま次の10年も過ぎ去りそうなので指摘してしまおう。

今後、コードをデータとして持つときは、次の二点を考慮して扱ってください。

  • 外部インタフェースであるコード(ユーザの都合で変わるコード)と内部の実装で取りまわすためのコード(identifier)は別にすること
  • 他システムは自分のシステムから見たらお客さんであり、コードがお客さんの都合に左右されることを考えたら、他システムで使うコードもやっぱり内部の実装からは切り離した設計にすること

たとえば、こんなシステムの話です。GUIからコードとその名称を入力値として受け取り、DBへ一時保存します。そして、あるタイミングでそのコードを他システムへ送信します。送信された先ではそのコードを使って集計・分析をします。

こんなときに、現在の実装は次のような形になっているのです。
「GUIで表示されるコード」=「DBへ保存されるコード」=「他システムへ送信されるコード」

これでは柔軟性がありません。どこかのコードを修正する必要が出た場合、すべてのコードについて対応の有無を検討する必要が出てきます。

そこで、よりやわらかい設計にするためにこんなふうにしてみます。

  • GUIで表示されるコード・名称を管理するテーブル(ID, コード, 表示名称)
  • 他システムへ送信されるコードを管理するテーブル(ID, コード)
  • コード間マップ(ID, GUIコードのID, 他システムコードのID)
ポイントは、二つです。
  • IDを導入して、内部実装のコード(ID)と外部へ公開されるコードを分離すること
  • コード間マップへの CREATE/READ/UPDATE/DELETE を通してコードの有効・無効を表現できること
これによって、たとえば次のような仕様変更へも柔軟に対応できるようになります。
  • 表示コードのコード体系を刷新したい
  • 他システムの都合で他システムのコード体系を刷新したい
  • いっそ表示も他システムもまとめてコード体系を刷新したい
  • 他システムへ送信する際は特定の条件でコードを変換してほしい
また、コード間マップへ「開始日」「終了日」のようなものを追加して、論理削除の扱いにすれば、「すべてのコード体系を刷新したいが、データが作成された際のコード体系に従ったコードが表示・送信されるようにしてほしい」というような複雑な要求にも応えることができます。

一方で、元のデータ設計へ戻って考えてみてください。これらの仕様変更のどれか一つに対応するにしても、影響や開発量はけして馬鹿になるものではありません。

と、長々と書きましたが、次の本を読んだほうが話は早いのでぜひ読んでください。

楽々ERDレッスン
楽々ERDレッスン
posted with amazlet on 06.07.19
(株)スターロジック 羽生 章洋
翔泳社 (2006/04/18)

ちなみに Identifier とコードの話だけであれば、これだけでも十分です。

Web+DB press (Vol.21)
Web+DB press (Vol.21)
posted with amazlet on 06.07.19

技術評論社 (2004/06)
売り上げランキング: 280,774