従来の典型的なWebアプリの設計では、下図のように主にサービス層がEntityを包含するイメージとなる。オブジェクト設計をすることで、Serviceを見いだすという段取りとなるが、ここでも述べたとおりうまくいっていない。
一方、Reflexでは、ここ で説明したように、オブジェクト設計をやらず、ドメインを単なるデータの集合とみなす。Entityという形で取り出したデータをシステム全体で使用し、また、サービス（Blogic）を各層で実装するため下図のようなきれいな3層構造となる。
このような新しい３層アーキテクチャは、RESTfulな設計思想に基づいている。つまり、RESTのような疎結合APIがなければ実現できないモデルである。特に、AJAXやMashupの概念は重要で、サーバでHTMLを生成するのではなくクライアントとはデータだけをやりとりする。
APIをやめデータ構造に着目するより抜粋
これは要するに、システム共通のentityを定義して、それをやりとりすることだけに注力しようということだ。SOAPやAtomPubなどのAPIを介さないし、そのような共通APIに該当するものを敢えて開発しない。しかし、最低限は必要になるので、先に挙げたリソース志向を踏まえて定義する。具体的には次のような非常にシンプルなAPIを定義することになる。
＜API例（entityはリソースの１インスタンス）＞
entity = create(entity);
entity = retrieve(entity);
entity = update(entity);
entity = delete(entity);
＜関連＞
ヘテロ環境のインターオペラビリティを考える
6 件のコメント:
この Entity が、肝になってしまいます。小さな政府がその Entity と、URIなどを決めればいい、というのは明快ですっきりした考え方ですね。
まだ「ドメイン」的な考え方というものがきちんと理解できているか微妙ですが、業務が複雑であればあるほど、ドメインに注目した考え方は面白いと思います。
たとえば、うちが使えるかは検討していませんが、XX業界のXML 標準があるようですので、それを使えばいいのかなぁと。
まさに、これがポイントになります。
「大きな政府」はEntityのすべてを積極的に網羅的に管理するのに対して、「小さな政府」では、消極的な管理、つまり、新規サービス構築がトリガーとなって背中を押される形で必要に応じて定義していけばよいことがミソです。
シノニムなどを解消するためにマッシュアップで変換してしまえばよく汎用的である必要はありません。新規サービスのためだけにあってもいいのです。
全社的なボキャブラリの管理は、できればそれに越したことはありませんが、なかなかうまくいかないのが現状です。業界の XML 標準でどれくらいカバーできるか分かりませんが、もちろん、無いよりあった方がよいと思います。
全社的なボキャブラリの管理については、ちょっと悲観的に取り組まれた方がよいかもしれません。というのは、スキーマ作成にかかるコストが大きくなりがちだからです。
参考＝＞誂えスキーマを開発してはいけない理由
なるほどー。
ヘテロな環境をつなげたり、複雑な新しいシステム作りで、ドメインに着目した開発はいいポイントだったと思います。
一方で全体のボキャブラリ管理（や統一）は、商品の特性も違うので難しいんですね。
うーん、業界の標準 XML 表現があれば、小さな政府である XX プロジェクトは一番大変なところを楽できるかとも思ったのですが、そーいうわけでもなさそうですね。
少なくとも参考にする、というレベルで考えて見ます。シノニムなどをオントロジなどで吸収する、ような考えをしていました。
このディスカッションのポイントを、担当者に伝えるのは大きなチャレンジです。
よくよく考えてみると、うちのウェブシステムはドメイン的な考えを中心にやっています。
ここで言うドメイン層です。
http://handsout.jp/slide/371
セッションを管理して、情報をためていく View のところのエンティティと、
パーシステンスに CRUD する エンティティは、同じということなのかなぁ。
精査していませんが、いけそうな気がしています。
実はViewからResourceまで一貫したエンティティを扱うことを多くの開発者がTryしてきましたが結局だめでした。
「View のところのエンティティ」はOO的なエンティティですが、「パーシステンスに CRUD する エンティティ」では、最後はRDBのER的なエンティティにする必要があります。
私はこれをRDBの壁と読んでいます。＜参考＞ 貴族になって楽をしよう
O/Rマッピングはどこかに必ず存在しますが問題はそれをどこでやるかです。
Resource 層でやれるのであれば、「パーシステンスに CRUD するエンティティ」までをOO的に扱えるため綺麗なシステムになりますが、既存のサービスがR的なエンティティを返すようになっていれば、O/Rマッピングは MashupでやるかViewでやらざるをえません。
Reflexでは、どの層からでもサービスを呼べるようにしていますが、それはEntityの変換がどうしても必要になるからです。
誂えスキーマを開発してはいけない理由のリンクはここです。
コメントを投稿