<< 「状態の変化」のモデリング | main | たかが URI の設計、されど URI の設計 >>

「知りたいこと」を提供する 【パターン】

エンタープライズアプリケーションは、「関心事オブジェクト」の状態を管理し、必要な時に、必要な情報を、適切な利用者に提供するための道具。

初期のモデリングは「知りたいこと」の把握から始める。
新規に登録したり、状態を更新する機能はもちろん大切だけど、基本の目的である「知りたいこと」を手に入れる、という利用シーンから出発してみる。

2つの提供方法


情報の提供方法は、2つある。

ひとつは、 REST スタイルの 「GET」方式。

ユーザが、「情報の要求( GET コマンド )」を発行する。
システムは、要求された情報を、一定の表現形式で、ユーザに送り返す。

もうひとつは、イベント駆動型の、「通知」方式。(メッセージの送信)。
システムは、関心事オブジェクトの状態が変化したら、それを表現する「イベント」メッセージを作成し、適切な宛先に送る。

知りたいことを適切に伝える

両方提供することもあれば、片方だけのこともある。

モデリングの基本手順としては、

・利用者(アクター)の洗い出し
・利用者が、どんなことに関心を持っているかを「関心事オブジェクト」として表現。
・利用者への情報の提供方法の検討 ( GET 方式 and/or 通知方式 )

GET 方式のモデリング課題


REST スタイルなので、基本課題は、たった(?)の2つ。 「URI」と「表現形式」。

URI = 識別キー


最初の課題は、「知りたいこと」に「識別キー」をつけること。
REST スタイルのサービスの URI 設計です。

大切なポイントは、

query 式 ( bankaccount-inqury/?bank=smartbank&number=1230012&type=balance ... ) ではなく、URI で設計すること。

この場合なら、
http://smartbank.com/japan/aoyama/1230012
のような設計になる。

スマート銀行の日本の青山支店の 口座番号 1230012 に関心を持っている、という設計。

ユーザの知りたいことを、 URI 形式で、特定できないケースもでてくる。
そこがポイントで、「URI形式で特定できる」ところまで、具体案をみんなで、考えることがたいせつ。

みんなで考える過程で、ぼんやりとした「関心事」が、「関心事オブジェクト」として、だんだん、明確になってくる。

表現形式


URI が、決まれば、その GET リクエストが来た時、何を返すかの「表現形式」を設計する。
XML ドキュメントの設計、ということですね。

アンチパターン


まず、表現形式(XMLドキュメント) の項目の列強から入るパターン。

これは、エンタープライズアプリケーション開発の世界に蔓延している伝統的な病気ですね。

「知りたいこと」の「識別キー」の設計をあやふやにして、「データ項目」の一覧を出したがる。

「顧客」に番号つけて、それで、 GET リクエストすると、100項目も200項目を、データが戻ってくる、というような設計。

「何が知りたいか」、この文脈では、「どんな項目が必要か」ということを、ほとんど考えずに、なんでもかんでも、「顧客」オブジェクト(テーブル、XML)に詰め込む。

仕様の追加や変更が増えるたびに、項目が膨らんでいる。

どこでも、誰でも目にしている、アンチパターンですね。
肥大化して、意味の不明な項目だらけになってきって、結果的に、だれも、理解も変更もできない、というパターン。

アンチパターンにならないために


大切なのは、「知りたいことはなんだ」という議論。

URI のパスの設計の中に、contactInfo (連絡先)とか、purchaseHistory (購買履歴)とか、をどう、埋め込んでいくか、という設計を、まじめに繰り返すと、このアンチパターンからのがれることができる。

設計の選択肢として、

contactInfo/顧客ID
purchaseHistory/顧客ID

にするか、

顧客ID/contakuInfo
顧客ID/purchaseHistory

にするか。

前者の場合だと、 contactInfo だけを指定した場合は、全顧客の連絡先を一覧がでてくる。
後者の場合だと、顧客ID だけを指定すると、その顧客について、提供可能な、 情報リソース、(連絡先とか、購買履歴)の一覧がでてくる。

どちらの設計が、現在のアプリケーションに、適切だろう?

こういう検討をみんなですることで、そのアプリケーションの「関心事オブジェクト」の姿が具体的になってくるわけです。

こういう議論を経て URI (識別体系、識別キー)が決まってくると、表現形式は、わりと単純に決まることが多い。

何に関心があって、何が別の関心事かは、 URI ( 識別キー ) 設計の段階で、具体的に議論されているから。

---

ちょっと、中途半端だけど、別件が入ったので、ここで、いったん投稿しちゃいます。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
      1
2345678
9101112131415
16171819202122
23242526272829
30      
<< September 2018 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM