「第三回ボトムアップドメイン駆動設計」という成瀬さん（@nrslib）さんによる、ドメイン駆動設計のイベントに参加してきました。曖昧な理解でふわふわしていた箇所が、かなりつながった感覚があって大変ありがたい会でした。

公開していただいている資料

イベント中に話されていた資料はtwitterでシェアしていただいていました。

資料内での補足

ソフトウェアの関心事
人の営み、人に営みに境界線を引いて問題を解決する
- ex. 物流システムのドメイン：トラック・倉庫・荷物・荷揚げ...etc
- ドメインをモデリングする -> エンティティ・値オブジェクトはドメインモデル
ドメインの導き出しが一番重要
ドメインを抜きにしてはモデリングできない。ドメインに目を向けよう
- 精通する人に話を聞いてソフトウェアに必要なことを蒸留しよう = ドメインエキスパート

変更はトランザクションの単位という話をよく聞くが逆。変更の単位だから結果、トランザクションの単位になる

Q: 値オブジェクト、どういう場面に出会ったらを値オブジェクトにするのがいいんだろう、やらないほうがいい場面とかどういうところだろう#bu_ddd
— Kazuki Higashiguchi 技術書典6 け27 golang.tokyo (@hgsgtk) February 28, 2019

できるならやったほうがいいが、チームの反発具合によるところがある。ただ、有益だと思える箇所ならやったほうがいい。ブログの本文とかただのIDとか別にそこまでやらなくてもいいねっていう箇所は勘所。

実際に入れていくなら、今回の例の「製品コード」とか複数組み合わせがあってクラスにしたほうがいいといった、目に見えてメリットを感じやすいところからやる

非常に難しい問題。メソッド一つ一つクラスにする。「サークルのユーザーを取る」ときにサークルサービス？ユーザーサービス？そもそもクラスを分けちゃう。「サークルのユーザーを取る」というメソッドをもつクラスにする

いろんなエンティティなどを強調させるのであれば、それはアプリケーションサービス。ドメインサービスはエンティティ・バリューオブジェクトでは不自然なものをロジックにする

CQRSの概念を活用する。アプリケーションサービスの直下に複雑なSQLを書いてしまう。Queryはフロントの都合などが多い。その場合はREADMODELとしてのアプリケーションサービス。

理解が曖昧な状態で軽量DDD実践していたので、理解が深まり今のコードを改めて見直そうと思います。