<< エンタープライズアプリケーションのモデリングパターン | main | 関心事オブジェクトの識別 【パターン】 >>

アプリケーションの中核 : 関心事オブジェクト 【パターン】

アプリケーションソフトウェアの中核は、利用者の「関心事」を表現した、オブジェクト。

銀行の残高照会アプリであれば、「銀行口座」、本の注文サイトなら「本」、顧客サポート部門なら「顧客」。
仕事一般に使える「to-do 管理」アプリであれば「to-do タスク」が、その中心の関心事。

一般モデル


こういう「関心事」を表現する、一般モデル。(前の記事の図を再掲)

事業の関心事を表す

◎ 識別キー (名前、番号など、関心事を特定するための情報)
◎ 固定属性 (商品の説明、連絡先など、通常は、あまり変化しない属性)
◎ 変動属性 (変化することが正常で、変化しないことが異常な属性)
◎ 集約キー (グルーピングや集計のキー)

もっと、具体的に考えてみる。
(集約キーは、性格がちょっと、違うので、今回は、識別キー/固定属性/変動属性 の三つの具体例。)

銀行口座


銀行口座
コードにすると、こんな感じ。

class BankAccount {
 AccountNumber number ;
 Holder holder ;
 Money balance ;
}

口座の識別キーは、「口座番号」。

int とか String ではない。
銀行−支店−口座番号 という構造を持っている。だから、 AccountNumber オブジェクトにする。

口座の「名義」は「固定属性」。しょっちゅう変わるわけではない。
とりあえずは、「氏名」を想定。
振り込みの時の「名義」は、文字種類は、カタカナ限定で、使える文字に制限もある。 そこらへんのルールは、 Holder オブジェクトに持たせる。

残高は、しょっちゅう変わる「変動属性」
「金額」を扱うので、BigInteger という汎用の数値型ではなく、 Money 型を宣言する。

残高照会アプリの関心事は、「残高 (balance) 」なんだけど、それを、保持するオブジェクトには、「識別キー」として「口座番号」、「固定属性」として「名義」と組み合わせて、表現する。

識別キー 固定属性 変動属性 の3点セットが、関心事オブジェクトの基本パターン。

「名義」は「固定属性」としたけど、アプリケーションによっては、識別キーになる。

ただ、残高照会や振り込みでは、口座を特定する識別キーは、「口座番号」ということ。

また、ここでは、「入出金の履歴」を省いている。中核の関心事は、あくまでも、「現在の残高」。
「残高」という変動属性を扱うパターンとして、「出入り勘定」がある。これは、別の記事で詳細に取り上げます。

簡単なモデルだけど、口座番号、名義、残高それぞれ、いろいろな業務知識が背景にある。

そういう業務知識(ビジネスルール)の置き場所、表現の場が、BandAccount クラスと、そのパーツのクラスというわけだ。


本
コードにするとこんな感じ。

class Book
{
 Title title ;
 Description description ;
 Amount inventory ;
}

識別キーが、「タイトル」。
固定属性が、「内容の説明」。
変動属性が、「在庫数」。

一意識別という視点では、本の場合は、 ISBN というコードがある。
今回、この ISBN を識別キーに採用しなかったのは、一般の利用者が、本を探す時は、本の「タイトル」を使う、という普通の姿を、素直にモデリングしたから。

本の検索を、 REST スタイルの API サービスにするなら、 ISBN というのもあるかな?
もっとも、Amazon の場合は、URI に本のタイトルをそのまま使っていますね。

「内容の説明」は、普通は固定ですね。 (読者のレビュー、とかになると、それは、「追加」されていく変動属性になる)

本の注文サイトの場合、主な変動属性は、「在庫数」。ほんとうは「出荷可能数」というべきかな。

現在の在庫数だけなら、これも、「出入り勘定」パターン。銀行口座の残高と同じパターンを使える。

問題は、いろいろある。

同時に発注があった場合の、在庫数減の、トランザクション管理。
注文数より、在庫が少なかった場合に、入荷予定とかを使った、予約注文の可否。
...

ここらへんの突っ込んだ話は、「状態管理のためのパターン」として取り上げたいと思う。

顧客


エンタープライズアプリケーション、つまり、事業のための道具であれば、「顧客」こそ、いちばんの関心事。
事業を営むには、常に「顧客」が、関心事の中心であるべき。

だから、顧客管理のアプリケーションは、エンタープライズのソフトウェアで、中核中の中核なんだ。
顧客

識別キーは、「顧客の名前」。
一意識別の視点だと、「顧客番号」になるけど、実際の業務を素直にモデリングすると、識別の基本は、「名前」。

このモデルを、実際のアプリケーションの画面で考えると、

◎「顧客番号」検索よりも「名前検索」が必要
◎ 一覧画面は、顧客番号順ではなく、名前順に表示

という意味になる。

ちょっとしたモデルだけど、「識別キー」のとらえ方は、そのまま「検索画面」や「一覧画面」の仕様・設計に、直結する。

固定属性は、「連絡先」。
このモデルは、「顧客サポート」という文脈なので、「連絡する」ための情報を、もっとも関心のある「固定属性」としてモデリングした。

変動属性は「取引履歴」。
取引履歴は、「変化しない」ということは、異常な状態。

このモデルは、「最近、取引のない顧客を掘り起こすために、電話で、新商品のご案内をする」という業務を想定している。つまり、「履歴に変化がない」という「異常状態」を検知して、アクションを起こすためのアプリケーションのドメインモデル。

「取引の履歴」というのは、単純にいえば、個々の取引の記録を時系列に並べたタイムライン。
「履歴」の扱いは、いろいろ興味深いテーマがたくさんある。

これも「状態の管理ためのパターン」の一つとして、掘り下げたいと思っています。
時間がからむので、「予実管理のパターン」のネタでもある。

to do タスク


仕事をしている人なら、必ず必要なのが、タスクの管理。
タスク
良いアプリケーションがないのが実情ですね。

今、ある開発案件で、実際に、「タスク管理」のモデリングを始めたところ。
ちょっとしたモデリングの実況中継ですね。

識別キーは、「タスク番号」にした。これは、議論がいろいろある。

内部的には番号管理が必然。
でも、人間は、「タスク」をどうやって識別しているか?
番号じゃないようなあ。
ここらへんが、使いやすいタスク管理アプリの中核課題のひとつ、と思っている。

固定属性は「タスクの内容」。
これも、議論がある。
そもそも、「タスク」として認識した時点で、「確定した内容」にできないことが多いのでは?
「やらなきゃいけないことがある」という認識と、「具体的にやることの定義」とのギャップ、という問題意識ですね。

役に立つタスク管理アプリにするには、「タスク内容」を簡単に固定属性として作成できるような仕組みがカギになりそう、と思っている。
フリーテキストで、つぶやき的に書く、という選択肢も、考えてはみたけど、それより、「メールする」とか、典型的なタスク種類を決めておいたほうが、ワンタッチで使えて便利なんじゃないかなあ。

あるいは「タスク内容」は「変動属性」としてとらえる、という発想もありか?
やりはじめて、はじめてやるべきことが定義できた、というようなケース。

変動属性は、今は単純に「進捗状況」にしているけど、ここも奥が深い。
たとえば、「締切期日」は、たぶん、「変動属性」に近い。

タスクにとりかかってみると、「締切」は、変動するのは、正常な状態、というとらえ方も必要なんじゃないかと。

to do タスクは、実践の中で見つけたパターンというより、これから、パターンを探しに行く、ネタです。
おもしろそう。

アプリケーションの粒度


ここで取り上げた例は、単純といえば単純です。
昔であれば、アプリケーションのサイズが大きかったので、ここまで単純化したモデルで話をしても、あまりリアリティがなかった。

顧客、商品、注文、出荷、請求、...

たくさんの関心事オブジェクトを、同時にモデリングし、設計・実装する、という開発スタイル。

最近は、アプリケーションを、小さな単位で作って、それらを、組み合わせて連係させる、というスタイルが、やりやすくなってきた。

技術用語でいえば、

・REST スタイル
・非同期メッセージング や、 SEDA ( Staged Event Driven Architecture )
・SOA
・シングルサインオン
...

などが、現実の実践ネタになってきている。
フレームワークやモデリングパターンや設計・実装のパターンがいろいろ利用可能になってきた。

私自身、システムを設計する時、ここ2年くらいで、急速に、アプリケーションの粒度を小さくして、それを、連係させる、という設計スタイルに、シフトしてきている。

エンタープライズアプリケーションのドメインモデリングの「パターン言語」への取り組みも、こういう背景、方向感の中で、やりはじめたことなんです。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
2728293031  
<< May 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