<< Value Object ってなんだ? | main | ファウラーも、ケントベックも、 Value Object >>

Value Objects パターン あれこれ

ドメイン駆動設計(DDD)の、 Value Objects パターンの続き。

意味のあるカタマリにまとめる


前の記事に書いたように「項目が一つのオブジェクトだ!」という方向に走った、後日談。

・郵便番号オブジェクト
・都道府県オブジェクト
・市区町村オブジェクト
・町域オブジェクト
・番地オブジェクト
・建物オブジェクト
・部屋番号オブジェクト
....

住所を表すために、せっせと小さいなオブジェクトをつくって、...

ちょっと待て!

こういう単位がほんとうに業務の関心事なの?
業務で、建物名がどーたら、こーたら、という話しをしている?

そう、やりすぎだったんですね。

業務の関心事は、「住所」という単位。それも、「配送先」というもっと、明確な役割を持っている。

Domain-Driven Design を読み返したら、ちゃんと、この「意味のあるカタマリ」で考える、ということが書いてある。

まあ、あちこち、読み落としているんで、何度、読み返しても、新しい発見がある本です。

どうやって説明する?


Value Object は、何かを説明するのが、その一番の役割。

相手は、主に人間。

人間にとってわかりやすい説明とは、内容や利用シーンによって、いろいろ変わってくる。
製品の色とかも、省略形の記号みたいなものが良いときもあれば、フルの色名とか、英語と日本語を併記とかもある。

住所だって、2丁目 1−20 という形式もあれば、 2−10−20 もある。

「説明」が関心事の Value Object では、こういう「表現の形式」は重要な分析課題のひとつ。

また、住所は、いちおう構造を持っている。
でも、日本全国共通の構造はない。(例えば、京都の住所表記)
もちろん、外国まで対象にすることになると、なかなか構造化は難しい。

でも、人間は、異なった住所の表記パターンをいとも簡単に使いこなしている。
もちろん、あらゆる形式の住所の厳密なチェックをできる人はいないだろうけど、「へんだな」くらいの判断力は、住所が重要な関心事の業務担当者なら、あたりまえに持っている。

求人情報の「給与」なんかの表現も面白いテーマ。
みんな書き方が違うけど、仕事を探している人は、それなりに、うまく比較をするんですよね。
もちろん、厳密な比較演算ではなく、高い・安いの印象なんだろうけど、それなりに合理的な判断をする。

こういう人間の判断力の一部でも、ソフトウェアに組み込むことができれば、

・より適切な候補を提示する
・あきらかな間違いを警告する
・もしかしたら、というヒントを追加する
...

という「気の利いた」ソフトウェアを実現できる。

仕事を手伝ってくれる人が、そういう業務の知識を持っていてくれるほど、助かるでしょ?
ソフトウェアに期待されていることも、そういう「気の利いた」手伝いをしてくれること。

Value Object パターンで、「説明」という関心事に集中して、分析・設計・実装することで、こういう気の利いた、役にたつソフトウェアに少しでも近づける、というわけだ。

そのためには、モデルも設計もコードも、機会があるごとに、見直して、リファクタリングして、改善していく。

不変オブジェクトにする


Value Object の実装を考えるとき、一番のテーマがこれ。

簡単に言えば、Java の String オブジェクトです。

String オブジェクトは、最初に生成したら、内容は変更できない。
substring() で部分文字列を作った場合、元の内容はそのままで、新しい String オブジェクトができる。
変更できるメソッドは無い。別の String オブジェクトを作ることができるだけ。

Value Object の基本は、こういう不変オブジェクトにしなさいね、という説明が Domain-Driven Design にいろいろ書かれている。

正直言って、ぴんときていない。
性能面の懸念、整合性維持の問題、他システムとのデータ連携、...

いろいろな視点から、「不変オブジェクト」の良さを説明しているけど、あまりドメイン駆動設計らしくない説明に感じる。

実装や性能への配慮はもちろん重要。
でも、一つ前に Entity パターンが、問題領域の専門家の関心事を中心に話しをしているのに、Value Object パターンは、説明の大半が、この「不変オブジェクト」の議論。

ちょっと違和感がある。DDD を初めて読んだとき、このパターンで挫折したのも、ここらへんに関係があるかもしれない。

DDD の中でも、後からでてくる「しなやかな設計 Supple Design」の説明の中で、不変オブジェクトの話しがまたでてくる。

そちらのほうは、とても納得がいった。そこが理解できてから、本格的に、不変オブジェクト中心の設計を指向するようになった。

そこらへんの話しは、また後で書きたいと思う。

テーブルへのマッピング


Entity パターンとValue Object パターンで分析・設計すると、小さなオブジェクトがたくさん登場する。

テーブルにマッピングする場合、オブジェクト単位に別テーブルにする、という設計は現実的ではない。
じゃあ、どういう単位で実装するか?

ここは、結構悩ましい設計課題。

極端に大きなテーブルもダメだし、極端に小さなテーブルもダメ。
答えは、その間のどこかにあるはず。

とっても乱暴だけど、それなりに現場で役に立っている経験則。

10カラム超えると大きすぎるかもしれない。(役割が複雑になってくる)
3カラムくらいだと小さすぎるかもしれない。(ほんとうに意味のある単位じゃないかもしれない)

あとは、作成・更新が同じタイミング、同じ理由であれば、たぶん、一つのテーブル。
作成・更新が別のタイミング、別の理由のカラムがあれば、テーブルを分割することを検討。

中核の関心ごとに集中する


Value Object パターンは、「重要な関心事」に集中することがキーポイント。

実践の現場だと、詳細画面の議論になったりすると、20も30もの項目を、メリハリつけずに設計・実装しはじめちゃう。

これは、アンチパターンです。

業務の専門家は、モノゴトの何に関心があるか?

いつも「重要な関心事」の発見・設計・実装に、時間とエネルギーを使うこと。

やり方としては「これはひとまず後回し」というように、何かをいったん「捨てる(別の場所に退避する)」こと。

重要なものを選べ、というと、なかなか難しい。

とりあえず、後回し、を選ぶほうが、やりやすいことが多い。

詳細画面を複数考える


Value Object パターンの情報の元ネタは、詳細画面であることが多い。

詳細画面を「ひとつ」と考えると、いろいろな利用シーン、いろいろな関心事が混ざってきて、どの項目も重要、ということになりかねない。

作業の種類、業務の進捗の段階、利用者のタイプ、...

業務の専門家たちと話しをする時に、こういういくつかの視点で、関心事を切り分けることが大切。

結果的に、詳細画面はいくつもできる。

でも、ドメイン駆動設計で、ひとつひとつの Entity オブジェクト、 Value オブジェクト、最小限に絞り込まれた関連、という設計・実装ができると、いろいろな詳細画面は、楽に実現できるようになる。

同時、たくさんの種類の詳細画面を作るとは限らない。

使ってみて、詳細画面をより使いやすくバージョンアップするとかは、よくあること。
これも「複数の詳細画面」の実際の例。

ドメイン駆動設計にこだわって、開発するようになってから、こういう「バリエーション」とか「変更」が、楽に安全にできるようになってきた手ごたえはある。

少なくとも、コピペで乱造、というアンチパターンが起きなくなった。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
  12345
6789101112
13141516171819
20212223242526
27282930   
<< September 2020 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM