<< SOA も、ロバストネス分析で | main | 「状態の変化」のモデリング >>

ドメインオブジェクトは 「固定」属性と「変動」属性を見分けるべし 【パターン】

エンタープライズアプリケーションの中核になる、ドメインオブジェクトは、その事業の関心事を表現した、「関心事オブジェクト」

関心事オブジェクト

識別キー


どの関心事か、特定するための、「識別キー」が必須。

注文オブジェクトだったら「注文番号」。
顧客が関心事だったら、「顧客氏名」。
本が関心事だったら、「本のタイトル」。
...

「固定」属性と「変動」属性を見分ける


関心事オブジェクトは、利用者の問い合わせに答えるために、さまざまな「属性」を持っている。

注文だったら、注文内容、出荷状況、代金回収状況。
顧客だったら、注文履歴、連絡先。
本だったら、内容説明、在庫数(販売可能数)。
...

いろいろな属性情報は、「変更」という視点で、2つのグループに分かれる。

(1) 変更されない=異常 という属性
(2) 変更されない=正常 という属性

例えば、注文内容は、変更されないほうが正常。
でも、出荷状況が、いつまでも、「未出荷」のままとか、代金回収状況が、いつもでも、「未回収」のまま、というのは異常事態。

顧客だと、「注文履歴」は、頻繁に追加されるのが、正常(期待していること)。 一年以上、履歴が更新されなかったら、異常(困ったこと)。

本は、内容説明は、通常は、変更しない。在庫数は、頻繁に変わるのが正常。
売れて、追加で仕入れて、また売れて、というのが正常な(あるべき)姿。

この違いは、アプリケーションのモデリング、設計・実装に大きな影響がある。

固定と変動を見分けない【アンチパターン】


ありがちなのが、ドメインのオブジェクトの属性に、すべて setter をつける。
テーブル設計も、すべてのカラムは、どれでも、随時 update することを想定。

ようするに、「なんでも、いつでも、自由に」変更、という設計・実装。

これは、事業のやり方からみると、かなり、杜撰(ずさん)な設計。

事業の関心事とか、業務のやり方を、うまく支援できる仕組みになっていない、典型的なアンチパターン。

事業を支援する道具である、エンタープライズアプリケーションは、もっと、「固定」属性の扱いと、「変動」属性の扱いに、気を配る必要がある。

固定属性も、変更する可能性はある。 変動属性は、もちろん頻繁に変更する。 だから、すべて、同じように「変更可能」にしておけば、良い、というのは、業務の知識が貧弱すぎる。

固定属性の変更


固定属性は、最初に設定する時とか、変更する時には、「申請」とか「承認」の手続きがからむことが多い。
また、通常は固定なので、それが「変化」した時は、影響を受ける部門とか、顧客に、変更を通知すべきことが多い。

そういう「固定属性」の「登録の手続き」、「変更の手続き」、「変更の検出と通知」には、いろいろな業務上のルール、取り決めごとがたくさんある。

あるいは、ある時点からは、完全に「確定」させ、変更をさせない、取り決めがある場合も多い。
例えば、「注文内容」は、出荷指示後は、数量変更は不可とする、というようなケース。

固定属性の変更は、単純に、 setName() とか、 update name とかだけ、設計・実装しておけば済む話ではない。

これは「固定属性」だな、という当たりをつけたら、その「登録手続き」「変更手続き」「変更に関するルール」について、業務の知識を、うんと増やしながら、モデリングと、設計・実装をやる。

それが、業務のための道具を造る、ということ。

変動属性の変更


変動属性は、変更が、正常だから、どんどん、更新するようにしておく。
しかし、こちらも話は簡単ではない。

事業においては、なんでも、いつでも、どうにでも、変更して良いわけではない。

出荷状況は、一定のルールにのっとって、状態が変化していく。
ある時、とつぜん「出荷済」になるわけでもないし、また、「出荷済」が、いきなり、「未出荷」の戻っていいわけがない。

杜撰なアプリケーションだと、更新画面から、こんな乱暴な変更ができてしまう。なんどもそういうのを現場で見てきた。

業務をやっている人たちが、使い方に気をつけて、ひどいことにならないようにしているけど、この造りだと、必ず、事故がおきる。

そいういうアプリケーションを造ってはいかんわけです。

「変更」属性も、「どうやって変更するか」「どんな変更は正常化?」「異常な変更は何か?」という業務知識を、徹底的に掘り起こしながら、モデリングと設計・実装を進める。

属性のグルーピング


固定属性も、変動属性も、「変更のタイミング」が同じになる、属性のグループがある。

例えば、「連絡先」は、基本は固定の属性。
ただし、引っ越しとかのイベントが発生すると、連絡先を表すさまざまな属性が、一斉に変化する。
郵便番号、住所、電話番号、...

こういう、変化が同じタイミングで起きる属性をひとつのグループにする。
そして、変化のタイミングが異なる、属性を別のグループに分ける。

「変化」の視点で、グループ分け【パターン】


この、「変化」のタイミングが同じかどうかは、オブジェクトやテーブルの粒度設計で、基本の着眼点です。

オブジェクトやテーブルは、「同じタイミング(同じ理由)」で変化する属性が集まったものにする。

だから、「連絡先」は、顧客オブジェクトの中に、「郵便番号」「住所」「電話番号」とかいう持ち方をしない。

「連絡先」オブジェクトとして、別にくくりだす。

そうすると、「連絡先の登録」とか「連絡先の変更」とかの業務のルールを、この連絡先オブジェクトに、集めることができる。

これが、良質なドメインオブジェクトをモデリングし、設計・実装する、良い実践テクニック、つまり、モデリングの「パターン」。

エンタープライズアプリケーションは、「状態の変化」を適切に扱うための

・業務知識の獲得
・モデリング
・設計・実装
・実現の技術方式(アーキテクチャスタイルやフレームワーク)

が、中心課題になる。

最近、書き始めている、エンタープライズアプリケーションのためのモデリングの「パターン言語」も、「状態の変化」の扱いが中心テーマ。

そしての、この中心課題を、うまく扱うためには、

◎ 固定の属性と、変動の属性を分けて考えること (変化が正常か、異常かで区別)
◎ 同じタイミング(理由)で変化する属性をひとつのグループにまとめること
◎ 異なるタイミング(理由)で変化する属性は、別のグループに分けること

というのが鉄則になる。

もちろん、属性のグループが、「オブジェクト」や「テーブル」の有力候補というわけだ。

これから、いろいろ書こうと思っている「状態の変化」を扱モデリングパターン(と実装の技術)は、この「鉄則」が、前提になります。

つまり、同じタイミング(理由)で変化する、ひとかたまりのドメインオブジェクトの「状態の変化」を扱うための、いろいろなパターンを書きたいと思っている。

コメント
コメントする









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