<< 分析パターンはドメイン駆動設計のヒント | main | ドメイン駆動設計と「デザインパターン」の関係 >>

分析パターン : これだけは覚えておこう

DDD 11章 Applying Analysis Patterns (分析パターンの応用)では、例として、ファウラーのアナリシスパターンの6章「在庫管理と会計」をヒントに、モデルを改良する話しが載っている。

エンタープライズアプリケーションでは、「在庫管理(企業資産の管理)」は、いつも重要な関心事だし、事実を記録するときに「会計」の考え方とやり方は、基本中の基本。

でも、正直言って、ソフトウェア技術者がファウラーの「アナリシスパターン」の6章を読んで、「なるほどそうか」と、ピンとくるとは思えません。

もうちょっと、単純な原則があると思っている。

私が、自分で考えるときとか、若手の技術者に説明するときに、よく使っている、単純な分析パターンを4つ紹介したいと思います。

・記録は不変
・予実の管理
・連絡
・情報の集約

この4つをちゃんとやってくれるソフトウェアは、利用者にとって、役に立つし、ありがたいソフトウェアになる(はず)。

仕事仲間や、仕事の相手が

・きちんと「記録」して
・「予実管理」がしっかりしていて
・「連絡」がゆきとどいて
・要点をうまくまとめた資料を作ってくる

そういう人だと、すばらしいですよね。
ビジネスシーンで「役にたつソフトウェア」というのは、こういうビジネス活動の基本を、代理で自動的にやってくれたり、面倒なところをうまくサポートしてくれるソフトウエアなんです。

この4つのパターンは、ビジネス活動というドメイン(問題領域)の、基本事項を抜き出したもの。

記録は不変( immutable )パターン


エンタープライズアプリケーション基本の関心事は、「起こったこと(イベント)」を正確に記録すること。

「受注」「出荷」「入庫」「請求」「入金」「支払」...

分析パターンの言葉だと「イベント」とか「トランザクション」ですね。

二つの日時で記録


イベントは、「いつ(When)」を記録することが必須。

しかも、

・いつ発生したか?
・いつ記録したか?

が異なる場合も多い。
両方を記録するのが基本。

「誰が」と「何を」


「誰が」を明らかにするために Agent ( 組織、個人 ) への参照を持つ。
「何を」を明らかにするために、 Resource ( 商品、サービス、場所、道具、... ) への参照を持つ。

「イベント」オブジェクトは「関連」を表すオブジェクトです。

「顧客」と「商品」の関連として「注文」イベントが起きる。

「記録は不変( immutable )」パターン


そして、ビジネスのイベント記録の原則は、不変 ( immutable ) です。

一度記録したら、その記録を「削除」したり「変更」することを禁止する。

データベースで言えば、insert 文はOKだけど、update 文、 delete 文は ダメ、ということ。

insert だけで「削除」を表現するには、

・「取消」レコードを insert

する。「取消」レコードには、「元」レコードの参照番号が入っている。

「変更」は、

・「取消」レコードを insert
・「変更後」レコードを insert

する。

紙の伝票で「赤黒処理」と呼んでいるやり方ですね。

ソフトウェアの世界だと、Value Object が、immutable(不変)型ですね。
元のオブジェクトは変更せず、新しいオブジェクトを作ることだけを許すわけです。

締め切り前の修正


実際の業務では、ありとあらゆる修正を、すべて「不変(immutable)」で処理するわけではありません。

「確定」前であれば、上書き修正したり、物理的に廃棄(削除)できるのが、普通です。
単純な入力ミスは、必ず起きるので、「確定前」のデータは、簡単に修正・削除できるようにする。

問題は、何をもって「確定」とするかですね。いわゆる「締め」の問題。

・日単位の締め ( 例えば、 17:00 締め切り )
・月単位の締め ( いわゆる、「締め日」 )
・プロセスの手順単位の締め ( 受付完了後はだめ、承認後はだめ、とか)

「記録は不変」の原則は、より実践的には

・「確定前の修正の許容」
・「確定後の修正の禁止」

をきちんと分けて実現する。

こういう「起こったことを正確に記録」することが、エンタープライズアプリケーションの中核の機能になる。

「記録は不変」パターンは、会計システムや基幹システムだけでなく、「会議室の予約」とか、「レビューの記録」とか、いろいろな問題領域で、いつも考慮すべき、課題です。

ここがしっかりしたシステムは安心して使える。

安易にデータを update するシステムは、怪しい。
論理削除フラグを update するのも、 update なので、やっぱり怪しい。

こういう怪しいシステムを作ると、利用者側は、敏感に気がつく。そして、不安になって、

・紙ベースとか、別の方法でも記録する二重作業を続ける
・入力ボタンを押す前に、画面の前で、何度も確認をする。
...

こういう利用者の姿が日常的なら、そのシステムは「ろくでもない」のは明らか。
利用者は、システムを利用するために、かえって仕事が増えている。

「予実の管理」パターン


昔のエンタープライズアプリケーションの関心事は、起こった事実、「過去の記録」だけでした。

例えば、銀行だと、

・口座に入金があった
・口座から出金した

という「過去」を正確に記録することが、最重要の問題。

「過去の記録」指向のシステムは、ある意味、今では、システム化はおわっちゃってる。
今は、「予定」という「未来」のイベントを管理することに、重点が移っている。

先を読むためのシステム


在庫管理だと、昔は「入庫した」「出庫した」の記録だけ、というシステムでもよかった。

今は、「引き当て(出庫の予定)」と「入庫予定」をあわせて管理して、

・(現物はないけど)出荷可能
・品切れを「予測」して、必要量を発注
...

というような、「先を読んだ」アクションをするためのシステムが求められている。

・「予約」した
・「約束」した
・「予定」した
...

という「未来」についての情報を記録して管理できるのが、役に立つシステムになる。

実績で消しこんで、to-do を管理


予定の記録だけでは、実際には役に立たない。

「予定」したが、まだ「未処理」。これを知ることが、たいせつ。

ソフトウェア開発だと、「チケット(やるべきこと)」を発行して、作業が完了したら「クローズ」する。
この方法で、まだ未完了の「to-do」を管理する。

・「予定(やるべきこと)」を記録
・終わったら、「完了」を記録
・(差分の)「未処理」を管理

これが、「予実管理」パターンです。

・○○予約
・アクションアイテム管理
・to-do リスト
・未処理リスト
...

こういう「やるべきこと」情報を、適切に扱うのが、「予実管理」パターン。

「予定」と「実績」から、「未処理」を導出する。

「予定」の記録も不変( immutable )にする


予定なので、予定の変更とか、予定の取消とかは、当たり前の世界です。

でも、原則は、「不変」にすること。

「予定」データを物理的に上書き変更するのではなく、一度、作成した「予定」は、事実として記録しておく。
キャンセルとかも、「予定」した事実と、「キャンセル」した事実として記録する。

そうすると、「予定の変更」履歴が残る。
この情報は、業務の効率化とか、予定変更の傾向を分析して、今後の予測を支援するようなアプリケーションとか、より高度なソフトウェアに進化する可能性がでてくる。

物理削除や全面上書きのほうが、合理的なシーンもある。
でも、ソフトウェア技術者が考えるより、はるかに多くケースで「記録は不変」「予定の記録も不変」の原則が正しい。

ソースのバージョン管理システムも、「概念的」には、過去のすべてのバージョンを、そのまま保管していますよね。

「連絡」パターン


ビジネスでは、「連絡」しあうことが大切。「記録」と「連絡」が2大関心事。

イベント発生を「記録」するときに、あわせて、「通知」が必要なのではないか?という発想を持てば、業務のニーズや約束事を、さらに深く理解できる。

ビジネスイベントの発生には、必ず「利害関係者」がいます。
「ビジネスイベントの発生」を「利害関係者」は知りたいと思っている。

イベントが発生したら、「利害関係者」への通知することが、暗黙のルールであったり、「気配り」という差別化のチャンスになる。

先ほどの、予実管理パターンだと、「未処理が残っていたら、アラートしてくれる」「予定日が近づいたらリマインドしてくれる」とか「連絡」パターンを実践するシーンは多い。

「連絡」も体系的に取り組む


エンタープライズアプリケーションの根幹は、

・永続化(記録)
・通信(メッセージング)

の2つです。

実装レベルでは、永続化:データベース、メッセージング:非同期メッセージングとかですね。

ビジネスのレイヤで言えば、

・ビジネスイベントの記録
・ビジネスイベント発生の連絡

になります。
(連絡の実装手段は、概念的には、非同期メッセージングだけど、電子メールとかが多い)

情報システムの開発では、「永続化」は、わりと体系的に検討される。
「データデモリング」とか、「情報アーキテクチャ設計」という概念がある。

「連絡」は、個別のメール通知機能とか、詳細レベルの議論に埋もれちゃって、体系的に扱うことが少ない。

でも、ビジネス活動では、「連絡」というコミュニケーションは「記録」とならんだ中核の活動です。

ビジネス層での「ネットワークアーキテクチャ」として

・ネットワーク構造 (関係者とその接続関係)
・連絡時のプロトコル(形式や手順)

を、「業務の言葉」で、体系的にモデリング、設計することが大切。
ドメイン駆動設計の重要な課題のひとつです。

「連絡」モデルが洗練されるほど、利用者にとっては、ソフトウェアの価値が高まります。

なんかあったら連絡して!


何かあったら、連絡してほしい、というニーズ・ありがたさは、「連絡が欲しい」側にたてば、すぐにわかりますよね。
RSS は「変化があったら教えて」パターンの具体例ですね。
メール到着を教えてくれるエージェント機能もそう。

システムが、利用者の代わりに、利用者の関心事を監視して、イベントが発生したら、自動的に連絡してくれる。
そういう気の利いたアシスタントがいたら、うれしいですよね。

「連絡パターン」は、「気の利いた連絡がほしい」というニーズを、モデリングして、設計・実装すべし、という考え方です。

「情報の集約」パターン


ビジネスで起こる様々な事象を「記録」して、必要な人にこまめに「連絡」すると、膨大なデータが発生する。

CPU、メモリ、ディスク、ネットワークの単価が急速に下がり続けているので、大量のデータを扱うことは、ハードウェアレベルでは、対応しやすくなった。

問題は、その情報を扱う、人間側の能力とコストの問題。

自分に関連する細かい情報をすべて追跡するのは、人間の能力を超えている。
というか、コストパフォーマンスが悪すぎる。

人間は、とても高価だけど、とても、価値のある判断や行動ができる特別な存在。
情報システムは、そういう人間の役にたつことが目的の道具。

昔は、単純で定型的な処理を自動化するだけでも、「価値のあるシステム」だった。

・勤務時間を集計して、給与額を計算する
・売上データを集計して、売上総額を計算する
・入庫と出庫を増減して、残高を計算する
...

日々発生するイベント記録(トランザクションデータ)を集約して、「給与額」「売上総額」「残高」という、単純な情報に加工することが、重要な「システム価値」だった。

昔に比べ

・電子的に記録する(できる)データが飛躍的に増えた
・扱える情報の型式は、数字だからか、文字に、そして、画像や音声に拡大している
・あいまいな情報とか、個人の好みとか、も電子データとして扱う範囲が広がっている

データ総量は、天文学的なスケールで増大している。

こういう大量の情報を、どうやって集約してみせるかが、システムの価値を決める。

大量のデータを、「少ない」情報に、コンパクトに集約することが、システムの価値。

統計


100個の数字を、1つの数字であらわす、というパターンですね。
単純なものでは、「合計」とか「平均」。
いまでも、情報集約の基本はこれ。

もちろん「偏差値」とか「変化率」とかも、このジャンル。

最近は「変化」は数字よりも「グラフ」でビジュアルに見せることがあたりまえになってきた。

要約


100個の数字を、1つ数字で表す計算方法は、いろいろ確立している。

文字情報は、そうはいかない。
利用者のニーズにあわせて、大量の文字データを「要約」する設計が、システムの価値を左右する。

たとえば、「一覧」画面で表示する各項目の情報は、「詳細情報」の要約。

Google の検索結果は、該当ページの内容を、数行に要約していますよね。
また、Web アプリケーションでは、要約から詳細へのリンク、という設計・実装が普通ですね。

その場合も、要約の中のさらに、どの部分をアンカーにするかの設計の選択肢がでてくる。

「要約」は、情報の集約パターンとしては、かなり難易度の高いテーマです。

選別


大量データから選別して、小数のデータに絞り込むのも「情報集約」の基本パターン。
ほんとうに欲しいもの、重要なものだけに絞ってくれる価値ですね。

「検索」サービスが、典型ですね。

アマゾンの「お薦め」とかも、これかな。膨大な数の類似書籍から、小数に絞ってみせることで、役に立とうとしている。

検索機能の設計も「役に立つ」ソフトウェアの大きな設計テーマです。

並び替え


Google の検索は、「順番」をつけることで、大量の関連情報を、わかりやすく集約しているサービスの例ですね。

トップあるいは最初の画面で表示されるものに価値を感じている利用者が大半ですよね。

表示の「順番」の設計の巧拙は、想像以上に、システムの価値を左右する。

グルーピング


何かのテーマ別にグルーピングしてくれると、情報を扱いやすくなることが多い。

ファイルを、フォルダー構造で管理するパターンですね。
メールやメッセージの「スレッド」管理とかも、この一種。

役に立つ、素敵なソフトウェアは、この「グルーピング」のロジックが気が利いていることが多い。

過去のメールを単純に日付単位にグルーピングするより、

・今日
・昨日
・一週間以内
・一ヶ月以内
...

という「意味」のあるグループになっているほうが、使いやすですよね。
(一週間以上前のメールが日付単位でグルーピングされていても、普通はうれしくない)

利用者が自由にフォルダ作って管理、という機能は、実際には、面倒くさいことが多い。
実装上は、汎用にしておいてもいいけど、アプリケーションとしては、「こういうグルーピングがあったら便利」という「事前に定義したグルーピング」を提供することを追求したほうが、良いサービスになることが多い。

「なんでも自由にできる」ことが良いソフトウェアになるとは限らない。

ダッシュボード


ダッシュボードという機能(画面?)があります。

いろいろなテーマ・角度から情報を集約して、

・新着情報
・累計などの統計データ
・(動的に変わる)関連情報へのリンク
...

などを集めた画面ですね。

いろいろな「情報集約」パターンを、さらに「集約」した、画面ですね。

大量のデータを扱うようになると、忙しいビジネスマンにとって、よいダッシュボードは、ほんとうに価値のあるソフトウェアになります。

ろくでもない、なんちゃってダッシュボードもよく見かけますが...

分析パターンというほどりっぱなものではないけど...


ここで、紹介した4つのパターン

・記録は不変
・予実の管理
・連絡
・情報の集約

は、エンタープライズアプリケーションのモデリングや設計をしている時に、私がなかば無意識に使っている基本パターンです。

いままでの経験の中から、「喜んでもらえる」役に立つソフトウェアのポイントになる箇所だと思っている。

それなりにうまくできたと思ったソフトウェアの評価を「だいなし」にしてしまったアンチパターンの裏返し、ともいえるかな。

・データはなんでもかんでも、変更・削除可能
・起きたこと(過去)の記録しかできない(予定は人間が管理して予測)
・ログインして自分で調べにいかないと、状況がわからない
・データをエクセルで加工しなおさないと使えない
...

こういう、ろくでもないシステムを作らないための、自戒を込めた設計ガイドです。

コメント
コメントする









この記事のトラックバックURL
トラックバック
[DB][PostgreSQL][設計]PostgreSQLでINSERTのみ使用してレコードの更新履歴を残すテーブル構造を実装する
今関わっている案件でレコードの更新履歴があるとうれしいなという話を聞いて、 システム設計日記 http://masuda220.jugem.jp/?eid=350 の「記録は不変( immutable )」パターンを思い出して実装してみました。 ビジネスのイベント記録の原則は、不変 ( immutable ) で
  • 明日は明日の風が吹く
  • 2010/04/07 9:05 PM
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< March 2024 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM