<< アプリケーションの中核 : 関心事オブジェクト 【パターン】 | main | SOA も、ロバストネス分析で >>

関心事オブジェクトの識別 【パターン】

関心事オブジェクト


モデリングでは「識別」ネタは、基本だし、また、奥が深い。
「識別キーの分析・設計」だけで、本が一冊、書けると思う。

エンタープライズアプリケーションのモデリングパターンの基本としては、まず、「識別キー」はしっかり押さえておきたいところ。

識別キーについて、ざっと思いつく、参考情報:

■ Evans "Domain-Driven Design" の 「Entities パターン」
■ ファウラー "アナリシスパターン" の 5章「オブジェクトの参照」
■ Hruby "ビジネスパターンを使ったモデル駆動設計" の 「識別」パターン
■ Richardson "RESTful Web サービス" 4章の「URI」と「アドレス可能性」
■ データモデリングの、主キーの議論
...

などなど。

「識別」という関心事


識別という関心事は、「業務」の関心事でもあるし、ソフトウェアの実装技術の関心事でもある。

そして、二つは「全く別の関心事」である。

Java のオブジェクト(インスタンス)を、一意に識別する方法とか、データベース上のレコードを一意に識別する方法は、技術者としては、重要な関心事だけど、事業にとっては、全く関心のないこと。
GUID を使えば、一意性が確保できるとか、データベースのシーケンスの仕組みで、識別番号を生成する、とか、いうのは、実装上のテクニックの話し。

エンタープライズアプリケーションのモデリングのために考えるべきは、事業を営む上で、業務を行うときに、人間は、どうやって関心事を識別しているか? ということ。

人間のやっている識別のやり方をサポートするためのモデリングと設計・実装が「関心事オブジェクトの識別キー」のテーマです。

名前と番号


ファウラーが書いているように、人にとって、もっとも自然な識別方法は「名前」です。
だから、関心事オブジェクトの識別キーの有力候補は、いつも「名前」です。

個人の顧客であれば、氏名。法人顧客であれば、企業名が、識別キーのもっとも重要な候補。

ただし、「名前」は、一意識別を保証する仕組みではない。

そのために「番号」で、一意になるように識別することも、「業務」のテクニックとして、使っていることも多い。

この業務の関心事の「番号」と、データベースのシーケンス、という実装手段の候補を、分けて理解すること。

「名前」で一意に識別する


番号ではなく、「名前」で一意に識別しようという発想がある。

たとえば、ドメイン名。
名前も、登録制にして、一意性を保証している例。

もうちょっと技術よりの議論としては、

● プログラミング言語の「名前空間」(パッケージ構造)
● xmlns XML の「名前空間」
● URI により、リソースの識別

などがある。

URI は、番号での識別体系を含むこともあるので、厳密には、「名前空間」とは言えないかな?

「名前で一意識別」という考え方は、参考になる。

REST スタイルの、サービスとかの設計だと、URI の名前空間の設計は、「関心事オブジェクト」の「識別キー」のモデリングと設計・実装そのものになる。

検索キー、一覧の順番のキー


関心事オブジェクトの識別キーは、関心事を探すための主たる「検索キー」だし、その検索結果の一覧は、「識別キー」の自然な順番で、表示すべき。

「関心事オブジェクト」の「識別キー」のモデリングのヒントは、「検索」や「一覧」の画面の仕様と直接関係する。

複合検索とか、キーワードサーチとか、いろいろややこしい議論に埋もれがちだけど、「関心事の識別のキー」だけは、特別扱いで、徹底的に、分析し、関係者で合意することが大切。

そのアプリケーションの中核の関心事は何か?
その関心事は、業務的に、どうやって、識別しているか?

構造を持った識別キー


「銀行口座」の識別キーの「口座番号」は、「銀行」「支店」「口座番号」という構造をもった、識別情報。

識別キーは、単純に、 int や String では表現できないことも多い。

こういう構造を持ったキーは、ひとつのオブジェクトとしてモデリングして、設計・実装する。

「口座番号」オブジェクトですね。

郵便番号は、3桁-4桁の構造を持っているけど、その意味合いはちょっと怪しい。
電話番号は、国コード、地域コード、局番、加入番号という構造を持っている。

アプリケーションによって、この構造をどこまで、詳細に扱うかは、モデリングの選択肢ですね。

構造を持った、識別キーの入力フォームは、結構、面倒な問題が多い。

入力画面


銀行を選んだら、該当する支店の一覧がでる、というのは、ありがちな要望。
でも、Web アプリケーションでも、GUI のアプリケーションでも、一度、銀行を選択して、支店を選んで、口座番号を選んだ後に、銀行の選択を変更する、というシナリオで、ちゃんと動く画面をつくるのは、結構たいへんですね。

データベース


銀行+支店+口座番号でユニークという制約は必須。
複合キー3つを主キーとするか、主キーは、人工的なシーケンス番号等で実装するか?

ここらへんは、かなり実装よりの話しだけど、構造をもったキーを扱う時にはかならずでてくる問題ですね。

XML表現


電話番号 telephone 要素を、03-1234-9999 という形式で表現するか、city 要素、area 要素、number要素に分解するか?

識別キーとしては、ひとつの要素にすべきだと思うが、「構造を持っている」ことも重要な情報。
両方持たせる、という案もある。

人間の識別を重視しても、どちらともいえない部分がある。

ひとかたまりとして認識しているのではなく、市外局番とかは、たぶん、構造として認識している。

とすると、「市外局番」と「番号(市内局番+加入番号)」という構造にするのが、人間の識別の仕方を素直に表現したことになるかな?

これは、「市外局番」によっては、対応窓口が異なる業務、とかを表現したモデルになる。

ほんとうは一つの実体?


ソフトウエアの用意した仕組みで、関心事を識別したとする。

その時、二つのオブジェクトを作ったが、実は、同じ実体の情報だった、ということは十分にある。

東京店で買い物をして、登録された顧客と、大阪店で買い物をして登録された顧客が、同一人物だった、というようなケース。

こういう場合、オブジェクトをどうするか、というのも、識別キーの議論としては、とても興味深い問題。

ファウラーは、「複写・置換」、「乗っ取り」、「本質/外見」の三つのパターンを検討している。
なかなか興味深い議論です。

「複写・置換」は、二つのオブジェクトをどちらかに統合する。(片方の識別キーは消滅)。
「乗っ取り」は、片方のオブジェクトに統合するが、もう一方も記録としては残しておく。(識別キーは、2つのままになる。メインで使うのは、片方に特定)

「本質/外見」は、新しい「本質」のオブジェクトを作って、「識別キー」を新規に発行する。
そして、既存の2つのオブジェクトは、新規に生成した「本質オブジェクト」の「外見」というモデルにする。 識別キーは、三つになるわけだ。

どれが正解とかではなく、そのアプリケーションでは、そのドメインでは、どういうモデルが、もっとも、素直なモデルか、ということ。

これは、技術論でなく、「業務のやり方」「業務の考え方」に答えがある。

識別体系


これもファウラーの「アナリシスパターン」の5章「オブジェクトの参照」からの議論。

考え方としては、 xmlns : XML の名前空間や、 URN の考え方と同じです。

本の識別体系としては、 ISBN を採用していることを明示するパターン。

urn:isbn:1111322224444

という感じ。

識別キーは、ある名前空間の中で有効、というこの「識別体系」の考え方も、モデリングの上で、とても大切。

これは、業務の専門家と話していても、発見できない、基本構造であることが多い。

業務の専門家にとっては、ある識別体系を当たり前であって、それを「識別体系」として意識していない可能性が高い。

ただ、それだと、事業を展開していくときに、別の識別体系の情報を扱う必要が生まれたときに、破綻する。

「事業」のための道具である、エンタープライズアプリケーションのモデリング・設計では、こういうより広い視点からの「識別体系」の把握が、とても重要。

特に、現在のように、国際化とか、事業のアライアンスとか、異業種連携が、あたりまえの時代には、「識別キー」のモデリングには、「識別体系」の認識がとても重要。

異なる識別体系間の等価性


識別体系を別の名前空間として扱えばよいだけなら、話は簡単。

たいへんなのは、識別体系Aと、識別体系Bで、別々の識別キーを持った、関心事オブジェクトが、実体は同じ、あるいは、「等価」とみなす必要がある時。

A社の顧客番号と、B社の顧客番号は、別の識別体系だけど、両社が協業とか、合併とか、という話しになった瞬間に、この「等価性」の扱いが、大きな問題になる。

「名寄せ」問題ですね。


つきない課題


こうやって、識別キーの議論のネタは、いくらでもでてくる。

事業における関心事は何か?
そして、それを「識別するキー」は?
その識別方法の潜在的な課題は?
...

エンタープライズアプリケーションのモデリングでは、この「識別キー」は、基本中の基本の課題。

そして、ある識別体系に閉じた識別キーの問題でもたいへんなのに、異なる識別体系をまたがった識別の問題が、現実の問題として、大きくなってきている。

経済的には、事業の合従連衡とか、国際化、という大きな流れが背景にあるし、技術的には、インターネットが実現してしまった、膨大な情報空間の存在がある。

ひとつのアプリケーション開発で、どこまで考慮すべきか、ということ自体も悩ましい問題ですね。

あまりにも、ローカルな識別キーは、さすがに問題だろうけど、あまりに、汎用的な識別体系論議は、個別のアプリケーションが扱うべき問題ではないですね。

複数のアプリケーションを、エンタープライズとして統合し連係することを考えるとき、「識別キー」のモデリング、基本的な設計方針は、その企業の将来の事業展開に、大きな影響を与えることになる、ことを、意識して、取り組みたいと思う。

コメント
コメントする









この記事のトラックバック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