suusan2号の戯れ

SIerでインフラSE⇛WEB系でエンジニアのおっさん

実践ドメイン駆動設計を読んだ

実践ドメイン駆動設計を読んだ

 

実践ドメイン駆動設計

実践ドメイン駆動設計

 

会社でレガシーシステムのリニューアルをやっていて、それのコアとなるAPIサーバをDDDで作りたいと思い購入した。

エバンス本は既に一度読んでいたのだけれど、いざ実務になるとこれはどこに置いた方がいいんだ?とか、どう実装するべきなんだ?みたいなのは本当によく迷う。

この本で、そのあたりクリアになるんじゃないかなという期待を持っていた。

以下、感想

自分がやっていたのは軽量DDDだった

本書ではDDDの思想を理解せずに、そのアーキテクチャの実装だけを真似ることを軽量DDDと呼んでいて、あまりオススメしないと言っている。

実際、自分もやって見て思ったんだけど、ドメインとは何だろう?という問いにちゃんと答えられないとレイヤー分けが結構難しくなってくる気がする。

ビジネスロジックドメインなんでしょ?みたいな意識だけだと、複数人の開発で意識合わせていくの辛くなるんじゃないかなと漠然と思ってたので納得。

 

DDDとは特定の技術的なアーキテクチャのことではない

これはよく公開されているスライド見ててもよく誤用されてるし実際自分も DDDでやってますみたいなこと言っちゃうんだけど、レイヤードアーキテクチャ= DDDではないという話。

特定の技術に依存するものではない、でもヘキサゴナルアーキテクチャがオススメとは本書に書かれていた

 

エンティティとは?バリューオブジェクトとは?アプリケーションサービスとは?ドメインサービスとは?

このあたりは、概念としては分かっているつもりでも、いざ実装するとこれでいいんだっけ…ってなりがち。本書ではこれらについて具体的なコード例もつけて解説してくれているので、かなり参考になる。また理想的にはこうだけど、パフォーマンス要件とかで難しい場合もあるよねーといった現実的な話もしてくれるのが良かった。

でもこれもやはり、技術的なテクニックというだけの話ではなく、ドメインから導いていくということが大切だなとおもった。(特にアプリケーションサービス、ドメインサービスは単純にビジネスロジック置き場みたいな気持ちだとごちゃごちゃになっていきそう) 

全てをバリューオブジェクトにする必要はない

例えばBooleanの値であったり自己完結した数値だったりする場合など、その値自体で意味のある全体を成している場合にはバリューオブジェクトにする必要が無いということは書いてあった。

なんとなくDDDガチ勢の人って全てをバリューオブジェクトでラップする印象があったのでちょっと意外だった。(よく考えたらそりゃそうだという話ではあるけど)

一方でIDみたいなものはどんどんバリューオブジェクト化した方が良さそうなので、自分もやって行こうと思う。

まとめ

おもっていたよりも読みやすい本だった。表紙で損してる気がするw

これを呼んでエバンス本の方をまた読み返し、またこの本を読むみたいなことをすると、理解が深まりそう。 

作者が公開しているリポジトリも参考になるのでおススメです。

GitHub - VaughnVernon/IDDD_Samples: These are the sample Bounded Contexts from the book "Implementing Domain-Driven Design" by Vaughn Vernon: http://vaughnvernon.co/?page_id=168