BirthdayというValueObjectはありなのか？杉本氏（@sugimoto_kei）の考えのまとめ

たなかこういち @Tanaka9230

BirthdayにasLocalDateとcalcAgeというメソッドを生やすか、getDateとgetAgeというメソッドを生やすか、インターフェースなら、後者の方が本来"正しい"のでしょう。 twitter.com/sugimoto_kei/s…

杉本啓 @sugimoto_kei

「fisrtNameとlastNameはインスタンス変数として保持されているが、fullNameは保持されていない」という知識を隠すのが情報隠蔽であって、前者と後者を区別したら隠蔽にならないじゃないか。

2019-09-06 21:45:06

杉本啓 @sugimoto_kei

@Tanaka9230 僕としては、Birthdayというクラスを設けることについて、基本的には、違和感を感じます。誕生日は、人の集合を定義域とし日付の集合を値域とする関数であって、値集合ではないと思うからです。

たなかこういち @Tanaka9230

@sugimoto_kei 杉本さんのお考えは、次の疑似コードの(A)であるべきで(B)は違うと思う、 ということだと捉えて合ってるでしょうか？ pic.twitter.com/KCPFWlPdPa

拡大

杉本啓 @sugimoto_kei

@Tanaka9230 はい、合っています。Dateには時分秒の情報は含まれていない前提で。

杉本啓 @sugimoto_kei

@Tanaka9230 誕生日を日付と別のクラスにするのは年齢計算などをメソッドとしたいからでしょうが、年齢計算には満年齢や数え年、保険年齢などもありドメイン依存です。Personはそれら複数のドメインから依存されます。Personが依存する Birthday にこれらの概念を含めるとなれば、依存性の観点からも問題ですね。

杉本啓 @sugimoto_kei

@Tanaka9230 年齢計算のような、日付を使う特殊目的の計算にあっては、ドメイン依存の計算方式が、より一般的な概念である日付に依存するのであって、その逆ではないということです。だから、計算を日付に含めると、不必要な依存設計が持ち込まれるかあるいは、認識上の価値が少ない無数の日付クラスが生まれます。

たなかこういち @Tanaka9230

@sugimoto_kei 先ほど例示はtrait Personとしましたが、より実践的にはtrait Insuredとかなはずで、単なるPersonなど実践的には出てこないはずで、そうするとgetAgeの内容変わるはずでしょ？ といった理解で合ってるでしょうか？

杉本啓 @sugimoto_kei

@Tanaka9230 合っています。まあ、満年齢はどこでも使うでしょうから、Personに含めても問題ではないでしょうが、基本の話をすれば、年齢計算はドメイン依存ではないかと思います。

杉本啓 @sugimoto_kei

@Tanaka9230 DCIでいうならば「オブジェクト」ではなく、「ロール」の実装に含めるべき、ということになるかもしれませんね。

たなかこういち @Tanaka9230

@sugimoto_kei さらに考えまして、次の三つの論が展開されると思いました。 (1)ドメイン依存の関数をよりLeaf側のtraitに装備することの一般的な良し悪し (2)「ドメイン依存」の件、実は例示のコード全体がnamespace LifeInsurance配下にあることが前提だった場合 (3)何せ誕生日から年齢が導出できるとする関係の是非

たなかこういち @Tanaka9230

@sugimoto_kei 杉本さんは(1)は一般には、意味論的価値の薄いtraitを増産してしまいがちでよくない、という意見と理解しました。 (2)は、この前提があれば、例示の(B)でも意味論的に散乱してないと言えないでしょうか？

杉本啓 @sugimoto_kei

@Tanaka9230 (1)の「Leaf側」という言葉が理解出来ていません。どんな意味でしょうか？

たなかこういち @Tanaka9230

@sugimoto_kei 木構造があったときのRoot->Branch->Leafという意味でした。 PersonとBirthdayの例の(B)は、より葉側にはより一般なものを、より特殊なものはより根側に置かれるべきが、そうなってない例、という理解です。

杉本啓 @sugimoto_kei

@Tanaka9230 理解できました。ちょっと整理してお答えしますね。

がくぞ @gakuzzzz

BtoCだとbirthdayの内部表現はEither[LocalDate, MonthDay] にしたい場合があり、age はOption[Int] にしたくなる場合があったりする

杉本啓 @sugimoto_kei

@Tanaka9230 ① 基本的な考えは、最初のツイートに書いた通りです。僕は、誕生日は値集合ではなく、Personを定義域としDateを地域とする関数なので、値クラスとしてモデリングすることに違和感があります。モデルは私たちの認識の構造を出来るだけ素直に映すべきと思うのです。

杉本啓 @sugimoto_kei

@Tanaka9230 ②それを踏まえても、「誕生日としてあり得る日付の集合」をBirthdayクラスとしてモデル化することは可能です。しかし、それが表すのは日付の集合（Date）と変わらないし、妥当性検証ルールや文字列表記ルールなど、通常、値オブジェクトに結び付けられる知識に関しても両者に違いはないので、..（続）

杉本啓 @sugimoto_kei

@Tanaka9230 ...一般的に言えば Birthday クラスを設けるメリットはないと思います。

杉本啓 @sugimoto_kei

@Tanaka9230 ③ そうなると、ポイントは、年齢計算のような「ビジネスロジック」をどこに置くか、ということに絞られてきます。まず、日付(Date)クラスに含めるべきではないと思っています。年齢計算の方が日付より特殊なドメイン（コンテキスト）に属するからです。

杉本啓 @sugimoto_kei

@Tanaka9230 ④次に、年齢計算を含むBirthdayというクラスをここで再び登場させることも可能です。ただ、「誕生日」クラスを立てたとしても、年齢計算が誕生日（＋その他の情報）に依存しているのであって、その逆ではないという点は同じだ思うのですよね。誕生日は年齢計算の一要素に過ぎません。...(続く)

杉本啓 @sugimoto_kei

@Tanaka9230 ...だから Birthdayクラスに年齢計算を含めるのは（僕的には）NGなのです。Birthdayではなく、単に AgeCalcみたいなクラスを設ければよいと思います。AgeCalc.calculateAge(誕生日,現在日,年齢計算方法)みたいな、あるいは ageCalcMethod.calculateAge(誕生日,現在日)。

杉本啓 @sugimoto_kei

@Tanaka9230 ⑤その上で、たなかさんのご質問ですが、まず、基本として、たなかさんの先に出された例が traitであることを重く見ていませんでした。この点に起因して、やや、理解に混乱があるかもしれません。まず[1]について、ドメイン依存の関数を含むtraitを設けることは一般論として悪くないと思います。..(続)

杉本啓 @sugimoto_kei

@Tanaka9230 ...[2]については、namespace はドメインを区切るための仕組みであって、ドメインそのものではないので、むしろ、 AgeCalcみたいなクラスは、積極的に別の namespaceに配した方がよいと思います。...(続)

杉本啓 @sugimoto_kei

@Tanaka9230 ...[3]については、重要なポイントで、誕生日計算や納期計算みたいな「ビジネスルール」が、誕生日や納期といった単一の項目に基づくのはむしろ特殊例なのではないかと思います。基本的にはビジネスルールが複数の種類の値に依存するのであって、その逆ではないと思います。

杉本啓 @sugimoto_kei

@Tanaka9230 以上、以前から思っていたことを整理するよい機会になりました。たなかさん、良いご質問をありがとうございました。誤解があればご指摘を^^