【DDD・ドメイン駆動設計】Scalaでリポジトリ・IDなどを型パラメータで縛る意味
-
k_bigwheel
- 6997
- 15
- 3
- 0
-
- いいね！0
西田和史(k.bigwheel) 開発基盤EM
@k_bigwheel
まあぶっちゃけるとジェネリクスを使えばリポジトリがすべて1つの基底クラスでかけるじゃん！ってのはジェンリクスとリポジトリ概念を学んだ人間が一度は陥る麻疹の気がする。 大抵の人間は自分で失敗しないとわからない。
2019-03-06 21:14:31
Yoshinobu Kinugasa
@sp1rytus
@gakuzzzz scalaさわりはじめだった当時、かとじゅんコードに影響されたのは事実、なので、かとじゅんのせい。笑
2019-03-06 21:16:14
西田和史(k.bigwheel) 開発基盤EM
@k_bigwheel
階層構造やエンティティ・リポジトリなんかのキーワードだけ使ってオレオレDDDやるコード、よくあるよね。 twitter.com/tototoshi/stat…
2019-03-06 21:34:10
Toshiyuki Takahashi
@tototoshi
この前SparkのコードなのにDDDとクリーンアーキテクチャのWebアプリ風の作りをしてるコードに出会ってほとんど消すということがあった。（複雑だからとかじゃなくて概念の理解が全て間違っていたため）
2019-03-06 19:54:21
西田和史(k.bigwheel) 開発基盤EM
@k_bigwheel
マーカートレイトってやつですね。 XxxEntityとかXxxValueObjectみたいに名前へsuffix付けている場合は悲しいほど不要。 suffixを付けずDDDでいうモジュール(意味的集合でのパッケージ分け)をする場合はそのクラスがEntityとValueObjectがひと目で見分けがつかなくなるのでそこそこ有用。 twitter.com/AoiroAoino/sta…
2019-03-06 21:39:47
ニャーニャーとなくどうぶつ
@AoiroAoino
trait Entity 定義するの見たこともやったこともあるけど、結局 id があるぞとか、これが Entity だ！って主張させるくらいで、それ以上突っ込んでもあんまり楽で幸せにはならなかったなぁ...
2019-03-06 19:49:53
このアカウントはフィクションです
@kiris
凝縮度とか疎結合とかもやりすぎればエンタープライズFizzBuzzみたいなことになる。 それよりもソフトウェア開発において一番コストが高いのはコミュニケーションなどの情報伝達コストだから、それが低いコードが良いコードであると捉え直したほうが上手くまわる
2019-03-06 22:43:26
このアカウントはフィクションです
@kiris
それはシンプルかつ素朴かつ自然なコードであり、それを実現するために各種の設計原則だったりDDDだったりを使ったり、逆にあえて使わなかったりする
2019-03-06 22:47:17
このアカウントはフィクションです
@kiris
そうすると、良いコードとはそのコードを扱う人達を定義しないとさだまらないともいえる。 どんなに素晴しくOOPやFPによって構造化されたコードでもそれを扱う人達が読めなかったり、伝えたい情報以上にコストがかかるコードだったらそれはクソコードだ
2019-03-06 22:54:07
このアカウントはフィクションです
@kiris
OSSにおける良いコードと業務における良いコードが違ってくるのもこのあたりだよなぁ。 OSSの良いコードをそのまま業務にもってくるとクソコードになったりする。
2019-03-06 23:01:54
このアカウントはフィクションです
@kiris
DDDや設計は将来における情報伝達コストを下げるための投資行為であり、それに反するあるいは投資効率にみあわないほど過剰におこなえばかえって害悪だ。 不要なことが書かれていない方が伝達率は良いに決ってる。
2019-03-06 23:08:31
このアカウントはフィクションです
@kiris
というわけで皆は設計原則を用いたツッコミ等を恐れて万人にとっての良いコードを目指すのではなく、そのコードを読むあなたの隣の人などにとって良いコードを書こうな！
2019-03-06 23:15:18
病気の美少女
@lyrical_logical
なんかある文脈の Entity trait ですが、こういうの明確な目的がないとあってもふにゃあになるやつですね、説明用とかでこういうコード使うことあるけれど現実は厳しいので使いたくても使えなかったりもするし使えてもメリット少ないとしょんぼりしがち。
2019-03-07 00:28:05
病気の美少女
@lyrical_logical
概念を説明する上では抽象的なコードの方がよい（ことがある）という話ですねえ という点で価値がないというわけではない
2019-03-07 00:30:36
病気の美少女
@lyrical_logical
もうちょっと真面目な話としては、巨大フレームワークとかで規約をコードに落とし込んで強制するパターンでは普通に有用で、それを普通のプロジェクトでやっても効果があんまりない（規約強制の仕組みコードにないと破綻するチームじゃなんにせよ辛い）という感じです、あと美少女はこういうコード好き
2019-03-07 00:45:28
加藤潤一(かとじゅん)
@j5ik2o
確か起源はこの辺。EntityやAggregateという型が必要かは議論が分かれるところですね。集約の境界を意識するためには型はあった方がよいと思ってます。そういう意味ではマーカートレイトでよいかも。 github.com/citerus/dddsam…
2019-03-07 05:05:40
加藤潤一(かとじゅん)
@j5ik2o
同一性や連続性をメソッドで検証するユースケースがあるならこれと同様にsameIdentityAsメソッドを定義したほうがよいかもしれないけど、要件によりますよね。identityメソッドはリポジトリの汎用的な実装を書くのに必要になることがありますね。
2019-03-07 05:05:41
加藤潤一(かとじゅん)
@j5ik2o
集約の境界を意識する目的は、不変条件の維持(DbC)・IO単位の明確化(トランザクション整合性の境界を明確化)だと思います。不正な状態遷移のガードであったり、集約の外側は結果整合の世界を理解しやすいなど。
2019-03-07 05:26:36
加藤潤一(かとじゅん)
@j5ik2o
できれば型レベルで不変条件を表明し、assertに頼らないようにできればマーカートレイト要らないかも。牛丼の種類をIntじゃなく列挙型でもらえばassertしなくていいわけですから。インターフェイス層では難しいかもしれないけどドメイン層に限ればやりやすいかも。
2019-03-07 05:35:21
加藤潤一(かとじゅん)
@j5ik2o
アンチパターンという主張は自由なのでよいですけど、PRを出すとか、記事を晒すとか、具体的なアクションにつなげたほうが生産的だし啓蒙になるのでどんどんやっていきませう。
2019-03-07 06:01:25
Kenji Yoshida
@xuwei_k
togetter.com/li/1325895 アンチパターンと言い切る自信もないのでそういう言い方になったが、とはいえみなさんが思ってる以上に(?)深く考えずtraitいくつか作って継承するみたいな感じではメリットかなり少ないと思うので、迷ってたらやらない方がいいというか他のことにリソース注いで欲しい感はある
2019-03-07 08:31:36
Kenji Yoshida
@xuwei_k
あくまでもDDD自体は全く否定してないというか(興味薄いので否定も肯定もするほど詳しくもないが)河内さんも言ってるが、おそらく設計というか全体的な構成作るときに意識する方が大事で、(そんな極端な人ほぼいないと思うが)trait継承しただけでDDD完璧にやってるつもりになってる人出たら不幸感ある
2019-03-07 08:39:35
西田和史(k.bigwheel) 開発基盤EM
@k_bigwheel
@Tanaka9230 すごく長くなってしまったのでgistにしました。 gist.github.com/bigwheel/0e333… pic.twitter.com/irdLJo9fEp
2019-03-07 09:36:25
拡大
西田和史(k.bigwheel) 開発基盤EM
@k_bigwheel
@Tanaka9230 ここまで書いておいてなんですが、文中でも濁している通り一概にアンチパターンと断ずるのは早計なんじゃないかと思っています。 文の最後に書きましたけど、うまく型パラメータや型システムを扱えていなくてひどいコードになっているのを見てこの手法はよくないと思っている人が多いんじゃないかと。
2019-03-07 09:38:44
たなかこういち
@Tanaka9230
@k_bigwheel めちゃめちゃ詳しくありがとうございます！ なるほど背景理解できました。 それ自体はアンチパターンとして捨てる程では無いが、メリット薄く、ミスったときのデメの方が大きいかな、というかんじですかねー。
2019-03-07 09:45:06