【DDD・ドメイン駆動設計】Scalaでリポジトリ・IDなどを型パラメータで縛る意味

がくぞ @gakuzzzz

@Tanaka9230 @j5ik2o 大きいのはカプセル化を破壊するという点でしょうか。github.com/ixias-net/ixia… 例えば今回のixiasの件ですと、Idは何らかのTaggedTypeであるという制約がついてます。この制約は本来Entityのユーザーは意識する必要がないものですが、型引数だとRepositoryの実装などに漏れだしています。(続

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

@Tanaka9230 ああ、その要約すごくいいですね！ まさに僕の気持ちはそんな感じです 👍

がくぞ @gakuzzzz

@Tanaka9230 @j5ik2o 継)もし後の改修でIdに制約を追加したいとなった場合、本来関知する必要が無いクラスまで修正する必要が出てきます。型メンバーを使った場合、これをEntityに閉じる事が可能です。アンチパターンというより、同じことをやるのにより適した方法があるよ、という感じですね。(続

がくぞ @gakuzzzz

@Tanaka9230 @j5ik2o で、じゃあJavaでどうするの？って件ですが、これは型引数でやるしかなくて、典型的なのはStream APIのCollectorの第二型引数ですね。 docs.oracle.com/javase/jp/8/do… Collectorsの殆どで第二型引数が?になっています。これは本来使う側が知る必要の無い実装詳細を関知させなければならないあらわれですね

たなかこういち @Tanaka9230

@gakuzzzz @j5ik2o めちゃありがとうございます！！(プルリク付き！) もう少々読み込みますー。

加藤潤一(かとじゅん) @j5ik2o

@k_bigwheel @Tanaka9230 コメントしました。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

@j5ik2o @Tanaka9230 全面的にかとじゅんさんの意見に賛成します。 基底クラスとして捉えるのではなくて機能のmix-inとして捉えれば十分有用に機能すると思います。 僕の2回の失敗は、両方共Repositoryの基底クラスとして置いてしまったことにありました。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

@j5ik2o @Tanaka9230 mix-inとして捉えたときの「リスコフの置換原則」上どう捉えるかですが、オブジェクト指向的な継承ではなくコード断片(メソッド)のmix-inになるので「リスコフの置換原則」の範疇外となり問題ない、というのが今の僕の考えです。

加藤潤一(かとじゅん) @j5ik2o

@k_bigwheel @Tanaka9230 こう考えると”継承”は使う機会減りましたね。extendsですがmix-inしてるというのもすこし違和感を覚えることが増えました。RustというかScala3みたいな委譲に誘導する設計スタイルのほうがいいですね。

西田和史(k.bigwheel) 開発基盤EM @k_bigwheel

@j5ik2o @Tanaka9230 そうなんですそうなんです！ mix-inなので A is B である必要はないんですが、scala2では構文上mix-inの場合でも A is B にならざるを得ないんですよねー。 でもScala3でなにか改善入りそうなんですか、それは期待だ 😄

Yoshinobu Kinugasa @sp1rytus

@tototoshi こちら社内弁護士に確認しました。該当のソースコードヘッダー部分にApacheのライセンス明記と、再利用元、参考にした箇所の明記を追加させていただきますね。よろしくお願いします。

Toshiyuki Takahashi @tototoshi

ライセンスに詳しい人として弁護士が出てきた回

Kenji Yoshida @xuwei_k

DDDで貢献といえばこれ github.com/scalikejdbc/dd… いくつか言ったようにEntityやIdentifierのtraitあるの特にすごく良いとも思ってないが、依存ライブラリの更新だけ自分ずっとやってるけど、そう思ってるなら中途半端に更新やらずに、(他の人がこれ以上改善する気ないなら)アーカイブとかするべきか？

Kazuhiro Sera (瀬良) @seratch_ja

@xuwei_k archive してもいいかもですね。私、全然見れてないですし...