「ＤＢ構造の前にＵＩを決める」というアンチパターン

業務に関するシステムを設計するための手法を身につけたエンジニア、プログラマは少ない。

　コーディングができるエンジニアやプログラマは、要望を聞き、プログラムを作ることに
エネルギーを費やすし、それが当然だと考える人も多いだろう。

　要望をオブジェクト指向によって、カプセル化する。カプセル化したクラスを、
コーディングによってつなぎ合わせていく。

　プログラミング言語の変数の中身は、揮発値である。保存のためにディスクを利用するが、
一般的には、データを保存処理するためのデータベースが利用され、
入出力インターフェースの記述が必要。

　保存される内容が単なる変数の磁気的記録であるなら、
磁気的なグローバル変数のようなものと考えられる。

　グローバル変数って、どこでどう変わるか判らないので使うのに苦労します。
せっかくオブジェクト指向でカプセル化したのにいきなり「振り出しに戻る」そんな感じがします。

こんな矛盾を何度となく経験して来た。

　渡辺幸三氏の著書を勉強する中で、データベースを磁気的グローバル変数として使うのではなく
様々な台帳を記録するための道具としてデータベースを利用するそんな、構成手法を学んだように思う。

　入出力の伝票イメージだけを記録し入力と出力のあいだをコーディングでつなぐ方法では
変更に対応できない。

データベースを適切に設計し、台帳を構築する手法があればコーディングの量を減らすことができます。

　ユーザーが希望する入力イメージ、出力イメージは、常に変更を求められる。
ユーザーは、画面イメージの源泉である情報が記録された台帳をイメージしている。
ユーザーの満足する台帳（帳簿組織）が完成しなければ、誰も幸せになれない。

　エンジニア、プログラマもユーザーと同じ目線で台帳をイメージしてみては如何だろうか。
コーディング、画面イメージへ先走らずに、冷静になって台帳の構成や、関係を整理することで、
要望の矛盾や思い込みに気がつき、コーディングの作り直しの予防にならないだろうか？

　渡辺幸三氏の「業務システムのための上流行程入門」では、データモデルのパターンとして
「汎用的な３つのパターンと２つのイディオム」を説明されています。

具体的なアンチパターンの説明もあります。

お読みでない方はご一読お勧めします。