このブログで何度も説明してきたように、UIを設計してそこからDBのあり方を導くようなやり方をとれば、よほど単純なシステムでない限り開発プロジェクトは失敗する運命にある。失敗とみなされなくても、生み出されるシステムは保守性が悪くバグが出やすいという難病を抱えることになる。そんなやり方ではなく、データ要件にもとづいてDB構造をまとめ、そこからUIを導くべきだ。しかしそのスタイルはなかなか普及しない。なぜか。 ■プロセス指向の危うさ 業務システムを代表とするデータベース処理システムはさまざまな要素で出来上がっているが、その基本要素といえるものが「アプリケーション」で、そのあり方は図1のように模式化できる。典型的なアプリはUI(ユーザインタフェース)とテーブルとの入出力を伴っており、UIを介してユーザの要求を受け取ったり、処理結果をユーザに示したりする。この意味で、「UI上の要素とテーブル上の要素
![危うい「プロセス指向」が廃れない理由 - 設計者の発言](https://cdn-ak-scissors.b.st-hatena.com/image/square/68fddc324f0a442a6394addd3ec53121e0ca40f1/height=288;version=1;width=512/https%3A%2F%2Fwatanabek.cocolog-nifty.com%2Fphotos%2Funcategorized%2F2017%2F11%2F17%2F20171117b.png)