暮らしのデザインサイト(
サイトの設計方針の一つはMashupである。つまり、自己完結したEntityの集合であるResourceをMashupして１つのページに編集する仕組みを取り入れること。また、ResourceをRESTfulにしてCoolURIとなるように設計することである。
例えば、サイトでは以下のようにCoolURIとなるように設計している。
２）  のように、category/{大カテゴリ}/{中カテゴリ}/{小カテゴリ}といったように、直感的なURL指定でカテゴリに属する商品の一覧を表示できる。また、{小カテゴリ}を省略すると{中カテゴリ}に属する/{小カテゴリ}の一覧が表示され、さらに{中カテゴリ}を省略すると{大カテゴリ}に属する{中カテゴリ}の一覧が表示される。
Resourceの設計ではまずEntityの正規化を考える。お互いに干渉するところのない、自己完結した集合を見いだすのがEntityの正規化である。例えば、単品の詳細ページとカテゴリは別々のEntityにできる。単品詳細ページでは商品の詳細情報をEntityとするが、カテゴリではEntityのURIの集合という形で定義する。（中カテゴリは小カテゴリの集合であり大カテゴリは中カテゴリの集合となる。）
このように単品の詳細ページとカテゴリは、同じ商品に関する情報であるが、お互いに干渉するところがないように、敢えて１つに括らないようにする。 また、そうすることで、商品情報プロバイダ、カテゴリプロバイダといったように、それぞれのサービスプロバイダを立てることができる。プロバイダでは単にXMLやJSONで出力できればよい。HTMLページを生成するのはMashupの仕事であり、それをPHPリクエスタが行っている。Reflex設計的に整理すると、サービスプロバイダがResource層、PHPリクエスタがMashup層、ブラウザがView層となる。
この考え方は、ソーシャルブックマークサービスと似ている。ブックマークサービスはHTMLページを管理するのではなく、リンクされるURLとそれに紐づくタグやコメントなどを管理するだけである。
Reflex設計による疎結合なサービス化がもたらすメリットは、主に並行開発ができるようになること、スケーラビリティが高くなることの２つである。特に商品情報とカテゴリについてはクラウド化などを見据えたときに非常に有効になる。クラウドではセキュリティ確保の心配があるが、そもそも商品情報は（原価などを除いて）人目に触れさせるべき情報なのでクラウドにフィットすると思われる。さらには商品詳細を静的なものとして分離してAmazonS3に置けばCDS対応もしているのでレスポンス速度向上も期待できる。ただし、商品詳細には商品ごとにお届け目安日や在庫数など、リアルタイム表示が要求される項目もあるので、ページ表示後にJSONPで再検索するなどの変更が必要となってくる。一方、お届け目安日の取得サービスや在庫数検索サービスなどは既に作成されているので、そのまま利用できる。
ちなみに、これらのサービスプロバイダはReflexで構築されている。