Naked Objects はドメインオブジェクトが中心的役割を担うアプリケーションを開発するためのアーキテクチャパターンでありフレームワークである。Naked Objects アプリケーションにおけるドメインオブジェクトはユーザインターフェースの中心部を形成し、開発作業の焦点である。Naked Objects は最近バージョン3.0をリリースした。これはJAVA1.5、サービスのインジェクション、従来のものに代わる UI、Hibernate を使ったオブジェクトの格納、統合セキュリティ、コントリビュートアクションをサポートするものである。同時に、Irish Department of Social and Family Affairs と進めている現行作業は引き続き Naked Objects の使用における価値のあるケーススタディを提供している。InfoQ は Naked Objects グループの共同設立者であり、Naked Objects パターンの発案者である Richard Pawson 氏と対話をする機会を得た。
Naked Objects パターンはデータと振る舞いを伴ったリッチなドメインモデルの供給に開発者が集中できるよう後押しし、自動的にビューレイヤと薄いコントローラレイヤを供給してくれる。
Naked Objects は次のような好循環に気付いたところから始まる。
もしあなたが完全な振る舞いを備えたドメインオブジェクトの設計に全力を傾けているなら、ユーザインターフェースではそれらのオブジェクトを直接見ることのできるビューと、メソッドへのアクセス手段をユーザに提供できれば十分だ。そしてこれはリフレクションを利用して自動的に行うことができる。もしユーザインターフェースをドメインオブジェクトが直接反映されたものにしたいのであれば、これは完全な振る舞いを備えたドメインオブジェクトを作成するのを強制し、助けるものになる。
これはドメインモデルがドメイン駆動設計といくつかの点で類似していることに焦点を置いている。
この二つは相補関係にあると思う。現在 DDD として知られる概念が、90年後半に私が Naked Objects を考え出すきっかけとなった。私たちは DDD のパターンのいくつかを Naked Objects に利用したのである。
DDD のアイデアに傾倒している人は皆 Naked Objects を使ったほうがよいと確信している。なぜなら Naked Objects は DDD の利点をより実際的で明白なものにするからだ。そして更にビジネスをプロセスに取り込みやすくする。私は長年の経験から UML ダイアグラムの議論にビジネススポンサーを引き込んではいけないということがわかった。これが人々が画面のワイヤフレームのようなシステム設計に頼る所以だ（関心しないアイディアである）。人々の関心を画面レイアウトの議論にひきつけるのは簡単だからだ。Naked Objects を使ってドメインモデルのプロトタイプを作ることはビジネスをの関わりを明確にすることを容易にするが、実際にはドメインモデルとダイレクトに関っているのである。
次に、私は Naked Objects と DDD には相乗作用があると考えている。なぜならドメインモデルの力が手書きのビュー＆コントローラによって削られてしまうことを防ぐからである。私のブログの最近の記事(source)でこのテーマについて述べている。
次に、Naked Objects がどのようにドメインを探求する手助けをするかについてさらに詳しく述べている。
私たちが NO を利用するにつれ学んでいるのは、その UI の包括的性質が、ドメインモデルに省かれているかもしれない必要な要素を組み込ませることを強制することである。それゆえにそのモデルは不十分で洗練さに欠けるところの一切ない、より現実の姿に近い表現なのである。その NO アプローチはビジネスそのもののコンセプトを明確にする。私が気に入っている例えは”前払い”と”後払い”。これは入札書類の原本に記載されていて、未払いのものと支払い済みのもの、といったように砕けていてわかりやすくなっている。しかし、私たちがした質問は、何がこれらの前払いをもたらすのかで、それに対する答えは、顧客が与えられた、前払いを受け取る権利である（恩給を受け取った結果として）。結果的に私たちは”前払い”を受給権利と命名するに至り、後払いは基本的にただの支払となったのである。これらの権利は事前に計算され（遡って変わるかもしれない）、一方支払いは期日が来たときに権利を完済するものである。
しかし Naked Objects はどのアプリケーションにも適しているというわけではないかもしれない。特に Richard 氏は顧客のアプリケーションに Naked Objects を利用することについて注意を呼びかけている。
Naked Objects を使って配布されたアプリケーションは内部使用についてのみ適していて、一般からのアクセスには適さない。私たちは決して生成されるユーザインターフェースが直観的であるとは主張していない。実際、普段から見慣れたものを除いて直感的なユーザインターフェースなどというものは存在しないことをリサーチが示している。明確な学習曲線が関係しているのである。しかし、私たちの狙いはいつでも、ユーザを単なるプロセスへの追随者ではなく問題の解決者として扱うユーザインターフェースを配布することである。
Naked Objects 3.0
Naked Objects 3.0 がサポートしているものには、フィールドの順序付け、ドメインモデルにシェアされたサービスのインジェクション、HTML とリッチクライアントインターフェース（更に可能性として Eclipse RCP、コマンドライン、AJAX）、ドメインモデル用のストレージを供給するための Hibernate との統合、ビルトインセキュリティモデル（データベース、フラットファイル、または LDAP で保管、管理できるもの）、コントリビュートアクション、Apache ライセンスへの移行のほか、宣言的な妥当性検証を実現するためのドメインクラスへの Java1.5 アノテーションの追加がある。
コントリビュートアクションはサービスがドメインモデルにアクションをコントリビュートしてユーザインターフェースの一部とすることを可能にする。これは開発者がドメインクラスから振る舞いを取り除き、サービスレイヤへ移行することを後押しする危険をはらむ。
最近私たちは、サービスのすべての振る舞いまで含めたアーキテクチャを SOA の線に沿ってすでに設計した（実装はしていない）と主張する大手顧客のために短期のプロジェクトを実行した。私たちは顧客のモデルのプロトタイプ（単に適当なエンティティを定義し、サービスにすべてのアクションへコントリビュートさせている）を高速に構築するために Naked Objects を利用することができた。私たちは絶対にこれを設計のパラダイムとして勧めないだろう。しかし、これは今までに彼らが行ったものとの作業か、あるいはまったくそうでないかの問題にすぎなかった。だがこの結果、私たちは顧客に彼らのサービスのコンセプトが不十分でとても一貫性のないものであることを示すことができ、そしてもちろんのこと、ドメインオブジェクトにできる限りの振る舞いを載せるというアイディアで始めていれば、もっとよい成果を出すことができていただろうことを話し合った。
私たちの見解では、コントリビュートアクションを利用するのは、継承することはできないが多くの型のオブジェクトに渡って実装させたい振る舞いがある場合だけにすべきである。これは単一継承の限界を克服する効果的な方法だ。コントリビュートアクションはコンパイルタイムでなくランタイムに起こることを除いて、AOP にとても似通っている。
Naked Objects ブログが調査した(source)とおり、アスペクト指向プログラミングと Naked Objects を連携させることは可能である。GPL から Apache ライセンスへの転換はユーザの声に答えたものだった。
残念なことに、GPL 製品を扱いたくないという人が極めて多い。加えて、このライセンスが、 Naked Objects 内で利用する他の多様なオープンソースライブラリと互換性があることを保証していることは私たちにとって大きな問題になりつつあった。
Naked Objects の採用に関して。
私たちは Naked Objects 3.0 の立ち上げにあたり、とてもよい反応を得た（最初の1週で1000件ものダウンロードがあった）。これは私たちが全面的に実際の利用が可能なプラットフォームと考える、Naked Objects の最初の実装である。私たちはニューリリースの通知を希望した何百もの人々が集まるメーリングリストを持っている。しかし、（ DSFA という驚くべき例外を別にして）まだまだ駆け出しのテクノロジだと言わざるを得ないだろう。恐らく、たいがいの人々は Naked Objects を、フル導入のためのプラットフォームとしてより、プロトタイピングツールとして利用しているだろう。私たちは今後数ヶ月間のうちに飛躍的な利用の成長を望んでいる。
私は多くの他のテクノロジが徐々に Naked Objects のコンセプトに近づいてきていると強く感じている（ Ruby on Rails や Spring ROO 等）。私たちはこれらのトレンドの論理的終点と思われる物へと突き進んだ。このため Naked Objects は、メインストリームの開発にとってしばしば過激（または独善的）だと見られる。恐らくそうであろう。しかし、私たちは実際に Naked Objects ができることを検証しているのであって、後戻りしているのではないのだ！
Richard Pawson 氏は自身のブログで Naked Objects と Ruby on Rails、Grails (source)との比較について詳細を述べている。
Naked Objects と Irish DSFA
DSFA は最も目に見える作動中の Naked Objects の例である。DSFA と Naked Objects との間の最初のパイロットプロジェクトは2002年に稼動を開始し、2004年と2007年9月現在の Naked Objects グループとの契約期間中続いた。アプリケーションは700以上ものユーザによって引き続き利用されるまで来た。
2007年5月、DSFA は新しいアーキテクチャを更に拡張し、さまざまな真新しいアプリケーションを開発し、既存のレガシーシステムを新しいプラットフォームに移行するために、新4ヶ年プログラムを発表した。この期間中、Naked Objects を通してアプリケーションにアクセスするユーザの数が数千にも上ることが見込まれている。
Richard Pawson氏は引き伸ばしになっているアーキテクチャの拡張についてコメントはできないが、次のステップがある限り、更なる拡張があること約束した。
従来のものに代わる自動生成ユーザインターフェース。新しい自動テストフレームワーク。開発ツール。だけど予告はしたくない。
DSFA プロジェクトに基づいて、ケーススタディ(source)は機敏性、プロトタイピング、再利用の利点について議論している。
次にコードの再利用についてさらに詳しく述べる。
これには二つ理由がある。一つは単に Naked Objects はすぐれたオブジェクトモデル（リッチな振る舞いを備えたエンティティ、数多くのポリモーフィズム）を後押ししていて、すぐれたオブジェクトモデルはよりすぐれた再利用に役立つからだ。そして二つ目に、Naked Objects 環境にあるアプリケーション間でドメインオブジェクトを再利用するときに、UI について心配する必要がないという理由である。あなたが従来のアーキテクチャで Customer オブジェクトを再利用したいとしよう。あなたは新しいビューとコントローラを書くか、ビューとコントローラが Customer オブジェクト以外とも関連していて、それをバラバラにしなくてはならなそうだということを発見するためだけに、前のアプリケーションからビューとコントローラを再利用する羽目になるだろう。
しかし、政治的要因もある。私の経験からして、もしあなたが多彩な利害関係者をある部屋にまとめて、 Customer に対する共通の定義について同意を試みたとしても、そんなのうまくいかない。彼らはそれぞれに特有の要求を含んだアイディアを乗り越えることはできない。だが、それぞれが望むことを彼らにやって見せることができるのなら簡単にいく。Naked Objects の成功は、共通の BOM がいかに各利害関係者に個々が必要としているものを提供できるかを、伝えるだけでなく、実際に示すこと、それにすべてがある。クラシックな UML モデルはそれができないのだ。
さらに読むには
Naked Objects について更に詳しく知るにはオフィシャルホームページ the official website(英語)、 または wikipedia entry (英語)、download the latest release(サイト・英語)、 Naked Objects Blog (source)へ。若しくは引き続き InfoQ の Naked Objects関連記事で。