地域、通貨は値オブジェクトかエンティティか？

Ryo Asai @ryoasai74

@koichik そうですね。ERでいうところのドメインやチェック制約は埋め込み値オブジェクトに近いとも言えます。でも、多くの場合、そういう使われ方をされていないとは思いますが。

koichik @koichik

@ryoasai74 それは真剣に ER やってる人達から見ると「RDB 使ってるだけ」で ER でも何でもない代物なのでは？ 「Java 使ってるだけ」で OO じゃない多くのコードと同じように．多くの場合の使われ方なんて，きっとそう．

Ryo Asai @ryoasai74

@kimukou_26 @shuji_w6e 私もやったけれど、これぞまさしくAOPの活躍するところだったりするわけですけれどね。after throwingアドバイスを使い、少なくともアプリ層やドメイン層からは意識させないのがレイヤ化されたきれいな設計ですね。

bohnen（草食系DevRel） @bohnen

@ryoasai74 んー、ちょっと勘違いがある気が。図7.7 は、インフラストラクチャ駆動のパッケージングが持つ問題を表す例（筆者がおすすめしない例）です。QT ツイートを追加。 http://togetter.com/li/131453

bohnen（草食系DevRel） @bohnen

@ryoasai74 金融システムがなぜ通貨、国をマスタデータとして持つかというと、これらは単なるコード値ではないからです。通貨に関わる属性（小数点以下桁数などの取引に関わる属性）や、国に関する属性を保持するため。RDBを使っているのは運用上のメリットのためですね

bohnen（草食系DevRel） @bohnen

@ryoasai74 そしてこれらは金融ドメインの根幹に関わるものなので、それなりの関連を持ちます。運用上のメリットの為と書きましたが、モデリング上国や通貨への関連は山ほどできるので、O/Rマッピング上はエンティティとして扱った方が都合がよいことは確かです。

bohnen（草食系DevRel） @bohnen

@ryoasai74 しかしモデリング上はこれらは値オブジェクトであることが多いです（私が知らないだけかもしれませんが、エンティティにしている例を見ない）。AさんBさんの取引は別ですが、それらが参照しているUSD, JPYといったコードで代表される通貨は同一です。

bohnen（草食系DevRel） @bohnen

@ryoasai74 コードは特定の値オブジェクトを指し示すボキャブラリーですが、実装上の識別子とはまた別であることに注意する必要があります。ドルを示すのにUSDを用いないケース(一意に決めた番号を使うケース)もあります。

bohnen（草食系DevRel） @bohnen

@ryoasai74 DDDのP.328でフライウェイトをドメインモデリングのパターンとしては適合するものがないことが述べられていますが、ここの記述も参考になると思います。

bohnen（草食系DevRel） @bohnen

@ryoasai74 私としてはマスタデータは値オブジェクトと考えますが、実装上エンティティにするという実装方針はOKです。ただ、それはその方が効率的だからという意味で、ドメインモデル的なエンティティと値オブジェクトの区別を曲げるものではないと思っています（終）

Ryo Asai @ryoasai74

@bohnen 金融システムのエキスパートからアドバイスをいただき、ありがとうございます。これこそ、もともと議論したかったことですね。マスメンの話ではなくて。w

Ryo Asai @ryoasai74

@bohnen 図7.7がアンチパターンということは理解しているのですが、7.8の図だとどれに分離しているからがわからないので、あえて7.7に言及したのですよね。これらがパッケージ以外一応対応づくという前提でどれをどのクラスに分離しているかが推測できるかと。#DDDjp

Ryo Asai @ryoasai74

@bohnen たしかに外貨の扱いが重要になる金融ドメインでは通貨は単なる記号ではないということですね。ただ、ここがよく理解できていないところなのですが、通貨属性というのはけっこう頻繁に変更されるもので、本当にDB上でメンテできる方が運用上メリットがあるかというところですね。

bohnen（草食系DevRel） @bohnen

@ryoasai74 私も以前悩んだことがあるのですが、通貨だけ取ればファイルでもなんでも、追加を準即時で反映できれば良いです。ただ先に述べたように関連が多いので、アドホッククエリや、実装での取り回しの良さを考えるとRDBが便利ではないでしょうか。

Ryo Asai @ryoasai74

@bohnen つまり、これらの属性が値オブジェクトに定数やロジックとしてハードコードされていたり、DIされるというのでは不都合なのかという点を知りたいです。

bohnen（草食系DevRel） @bohnen

@ryoasai74 アドホッククエリがなければそれでもOKだと思います。結構ありますよね、オンラインはJavaで、バッチはSQL+ストアドって。

Ryo Asai @ryoasai74

@bohnen 確かにルールを外部化するという考えは運用上大切で、複雑なロジックではルールベースなどというのもありますね。ただ、PGの発想ではきちんとDDDして値オブジェクトにや設定ファイルにカプセル化しておけば十分と思える時もありますね。

Ryo Asai @ryoasai74

@bohnen あと、もう一点ポイントは金融システムといっても実は一括りにできなくて、ユースケースによっては通貨が単なる記号でしかないシステムもあるのではということ。システムによってはエンティティになったり値になったりするというのがDDD的な考え方なのかなと思いますね。

bohnen（草食系DevRel） @bohnen

@ryoasai74 ですね。通貨や国もISOで決まっているすべてを取り込んでいるシステムというのはまず無くて、システムが興味のある範囲だけです。属性もシステムによってまちまち。だからこそ実装はフリーハンドで考えたいですね。

Ryo Asai @ryoasai74

それから、値オブジェクトは振る舞いや関連をもってはならないと勘違いしている人もいるかもしれませんが、少なくともDDD的には関連も振る舞いも持てますし、JPA2のembeddableもそう拡張された。ただし共有される場合は状態を可変にできないというところはある。#DDDjp

Ryo Asai @ryoasai74

まあ、でも実際時々値かエンティティかの分類がわからなくなることはよくありますね。全部オブジェクトではだめなのと開き直ってみたり。#DDDjp

Ryo Asai @ryoasai74

@bohnen P328の記述は誤訳に近いと理解しています。原文は「Why Not Flyweight」ですが、これは反語であり、訳としては「Flyweightを使ったらどうですか？」くらいの意味ですね。以下を参照 #DDDjp http://bit.ly/lXyoXq

bohnen（草食系DevRel） @bohnen

@ryoasai74 あれ。原書もあるので（←３年ほど積ん読）読んでみます！

Ryo Asai @ryoasai74

@bohnen つまり、ドメインモデルとしては直接一致するものがなくても値オブジェクトの実装方式としては有効な場合があるという説明がされています。原文を読むとちょっとニュアンスが違うような気がするのですよね。訳だと、完全否定しているように誤解されかねないですが。#DDDjp

Ryo Asai @ryoasai74

でも、Flyweightが実装方式として有効でもドメインモデルに現れるドメインパターンという意味では結局否定しているということか。もともとこのパターンは実装イディオムに近いですから。#DDDjp