ま、個人としての意思表明（ｗ。
設定ファイルが必要な理由
まず、現実論として設定ファイルが必要な理由。ひがさんのiRuleで書かれている
私は､設定だけでなく､コードもできる限り書かないほうが良いと思っている派です。それは、早く開発するためです。
については、当たり前ですが僕も設定やコードはできる限り書くべきではないと思っています。そのほうが楽だし便利です。でも、次の3つの理由からファイルとしては存在しているべきだとも思っています。
1つ目がプロジェクトとしての情報共有。たしかに開発スピードは重要な要素です。開発者個人にとっての開発速度は、いわゆる実装時間（コーディング、テスト、デバッグ）でしょう。しかし、プロジェクト全体で捕らえると新しいエンジニアの慣れる速度や他の人がコードを見たときの理解のスピードも含まれてくるはずです。ですから、プロジェクト全体の開発スピードを上げるためなら設定やコードも必要な分だけ書くべきです。
2つ目が検索性。実は、これ自体は本質的な議論ではないですが、現状のXMLファイルは単語マッチの検索機能が非常に便利です。大きなファイルになるとビジュアル化されていることよりも、文字列検索のほうがはるかにうれしかったりします。
3つ目がバージョン管理。ファイル化されていればCVSやSVNで差分を明示することが可能になります。僕は設定ファイルを積極的に利用して実装を変更するのが好きなので、これは非常に大切な要素です。
もちろん、これらをすべて手動で書けとは言いません。単純なところはどんどん自動化していけばよい。が、それは設定ファイルを自動生成すれば良いということです（Seasarも後で設定を生成して視覚化することができるので工夫次第で同じようなことはできると思います）。
ひがさんはXMLファイルの書き間違えコストの話をされていますが、これも設定作業が悪いというよりはツールや設定ファイルという存在の問題です。"設定を行う"という概念の問題ではないでしょう。
なぜ「設定を行う」ことが重要か
次に、「設定を行う」という概念の重要です。前回の書き方がよくないのですが、これからの「設定」というのはコードとは違うレベルの概念です。
設定と言うのはコードが形を変えただけだから､設定は書いたほうが良いけど､コードは書かないほうが良いというのは、矛盾している気がします。宣言的に書くのは良いけど、ロジックは書かないほうがよいというなら、合意します。
設定とコードって何だという問題はあるものの「宣言的に書くのは良いけど、ロジックは書かないほうがよい」というには合意です。ただ、宣言的に書くだけでは足らないから、やっぱり設定という言葉が重要だと思います。
たぶん、これからのエンタープライズ開発では「ロジックコンポーネントを書く人」と「それを使う人」が今まで以上に明確に分離してくるはずです。そのためには「それを使う人」が、いわゆる設定ファイルの記述やSOAのビジュアルツールみたいに痒いところに手が届かない方法ではなくて、スクリプトや宣言的記述のように"良い感じ"に書けるようになるようになる必要があります。
SOAの失敗はエンドユーザーには難しく開発者として大雑把過ぎる中途半端なツールにあったわけです。これはビジョンや問題設定が理想論過ぎてしまったことが原因です。そこからのゆり戻しとしてRonRを捕らえると、設定の重要性が増すなかで「いかにいい感じに設定するのか」という挑戦として僕には見えています。
僕は「設定によってアプリケーションを完成させる」という感覚がアーキテクチャとして美しいという思いが強い。SOAの実装はだめですが概念はきれい。特に最近のSOAがイベント中心になってきているのは当然の流れで、これからのエンタープライズ・アプリケーションでは「ロジックからイベントを切り離す」というのが重要になってくることでしょう。
その場合、イベントからロジックを呼び出すのは「設定を行う」という感覚が近い。このイベントには、イベントごとのバリデーションや起動条件、あるいは入力項目などの細かい処理設定が必要になります。こいつらをこれまでのような設定ファイルとコードだけで表現するのは難しいのです。
ビジネス視点から考えるとデータ中心や画面中心からも離れて、もっとビジネスそのものに中心をおくような設計モデルが必要なのです。この場合に設定という概念はとても重要なのです。
話が逸れたように思われるかもしれませんが僕が持っているコンテキストの原点はたぶんここらへんです。だから、「規約があれば設定はいらない」といわれると、ちょっと違うなぁと感じるのです。
DIされるだろうクラスをビジュアルに確認できるようになりました。
すばらしい。ぐっじょぶ。
