<< ドメインを分離しつづける | main | Smart UI から抜け出すきっかけ >>

Smart UI が優れている?

Domain-Driven Design (DDD) で、アンチパターンとして取り上げられている Smart UI 。

ある文脈( context ) では、Smart UI はとても優れている。(と、エバンスも書いている)
実際、私たちが、取り組んだ5年前の開発プロジェクトでは、徹底して、Smart UI でがんばった。

プロジェクトの背景


・短期間に既存のアプリを作り変えたかった
・中核メンバーは、寄せ集め。( 設計や実装について、経験や考え方が見事にばらばら )
・多数の作業者は、一年目のジュニアたち
・既存システムのソースコードは、ない。

Visual Studio で、画面量産


既存システムがあるわけだから、とりあえず、

・画面の一覧、すべての画面のHTML
・テーブル一覧、テーブル設計と実データ

は、そろっている。

400画面くらいをメンバー10人に割り振って、ひとりあたり、40画面くらいを、とにかく作れ、プロジェクトスタート。

データベースは、既存のものをまるっとコピーに近い感じで、まず、用意しちゃう。

後は、それぞれ、画面をフォームデザイナでマウスで作って、ユーザと確認して、DBのアクセスコードを書いて、それなりの動く画面がどんどん出来ちゃう。 

なんという生産性だ!! すばらしい!!

画面単位の縦割りを徹底しているので、お互いの開発に依存することはまったくない。 Aさんの仕事が遅れようが、Bさんの仕事は、さくさく進む。

タスクの依存関係を心配しなくいいプロジェクト管理はほんと楽。 これが疎結合の設計の良さだあ!!

どうせ作り直すんだから、もちろん、改善要望とか、機能の追加・拡張依頼も多い。
ボタンを一個追加して、そこにロジックを書けば、新機能が一丁あがり。
似た画面をまるっとコピーして、新機能を追加も朝飯前。

ユーザの要望に応じて、機能を簡単に追加できる。動く画面ですぐ試せる。ユーザは超ハッピー!!

3ヶ月もすると、たくさんの動く画面ができあがっている。
1年目の新人だって、同じタイプの画面(機能)であれば、器用なやつは、コピって、自力で新しい画面を作れるくらいになってきた。

未経験者がこれだけ開発できる。開発手法の革命だ!! Visual Studio すげー!!

じゃあ、連携させてみよう


画面間で関係するデータは、データベースで共有しているので、登録したら、それを他のメンバーが作った検索画面
で読み出す。あたりまえのように動く。

セッションで保持したデータのキー名が重複していたので、そこは、手の早い開発者が、キー名を変更して、さくっと、ビルド。 何にも問題ない。

なんだ、3ヶ月で、だいたい動くようになっちゃった。

でるわ、でるわ


表面的には、大成功のはずだったんだけど、ソフトウェアの内部で進行していたことは、悲惨なものだった。

・テーブルの同じカラムを別の用途で使う(IDと管理番号は、別の体系なんだってさあ)
・セッションのキー名が同じでも別の内容( おれは、SERVICE_TYPE は、数字で区別しているよ、そっちは略称?)
・入力データの検証がかなり怪しいね。特に新人たちが書いた部分。(ありゃ、なにもしていない)
・そっちで削除しても、こっちのデータは消さないで!! 別の用途でも使っているから?
・あれ、ここ一意キーじゃないの? 重複しているよ。 しょうがない DISTINCT で一意にしちゃえ。
・このエラーメッセージ、あっちの画面の内容のままなんですけど。
...

末路は悲惨でした。

・つぶしても、つぶしても、不整合がなくならない。
・臭いものにフタをしたつもりのコードが、さらに障害を発生する。
・こわくて、削除系、取消系の機能は使えない(使ったら、動作は保障しません)
...

何がいけなかった?


・画面単位に縦割りにして、
・疎結合にして
・GUI開発ツールを駆使すれば
大成功のはずだった。マイクロソフトもそういっていた。 Visual Studio , .NET フレームワークは、開発の革命なんだと。

寄せ集めの中堅技術者と新人で、短期間で結果を出すのに、ほかにどんな選択肢があっただろう?

エンタープライズアプリケーションの本質の課題のひとつに「連携」がある ( by マーチン・ファウラー )。

ビジネスの作業、業務、データは、単独で存在することはありえず、必ず、別の作業、業務、データと関係している。

単独のアプリケーションや、疎結合で独立性の高い機能群であっても、そのシステムの背景、本来の目的は、必ず、他の機能や情報との連携である。

例えば、「登録」と「削除」は、別々に開発することはできるけど、本質は、連携した機能。

利用者、商品、場所などのビジネスの資源に管理番号をつけて識別するのは、特定の機能だけでなく、さまざまな機能、利用シーンで、一貫して、追跡するための共通の関心事。

一つのビジネスイベントが発生したら、そこを起点に、関連するさまざま業務が発生して、連携しながら、ビジネスのプロセスが進行していく。 そのプロセスの文脈(コンテキスト)では、一貫した関連情報や進行状況の管理が必要。

400画面を10人で分割して、画面単位に完全に縦割りで開発する方法は、この密接に関係したビジネスの業務の流れ、情報の一貫性を軽視しすぎた。

技術的には、個々の画面は、セッションとデータベースで、連携できる。
でも、それは「可能」であるだけ。

実際に「うまく連携できる」のは、「連携」を重視した、分析・設計・実装・テストをした時だけ。
連携の技術方式は、「連携の成功」を保証はしてくれない。

作業、業務、情報の「連携」というエンタープライズアプリケーションの中核の問題に、もっと正面から取り組むべきだった。

じゃあ、どうすればよい?


それはドメイン駆動設計です。
でも、実際には、こんな掛け声だけでは、何も解決しませんよね。

私たちが、この Smart UI 方式で陥った地獄から、どうやって、抜け出そうとしたかは、次の記事で。

コメント
いやあ、読んだだけで泣けてきます。。
文章を読んだだけでこんな簡単にいやな汗を書いたのは初めてです。。。
  • kagehiens
  • 2014/03/09 9:16 PM
kagehiens さん

コメントありがとうございます。
  • masuda220
  • 2014/03/10 12:54 PM
コメントする









この記事のトラックバックURL
トラックバック
calendar
    123
45678910
11121314151617
18192021222324
252627282930 
<< June 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM