ffffffff# 【DDDの実態と課題】ドメイン駆動設計について改めて語ろう会

## 注意事項

- 勉強会の様子はリアルタイム配信 & 後日編集した動画としてYoutubeにて公開させて頂きます
- 顔出し NG の方は遠慮なくおっしゃってください
- ゴミは各自で持ち帰ってください

## お願い

- ハッシュタグ `#ペチオブ` で勉強会の様子を Tweet してね！
- [Discord](https://discord.gg/d3xxrYEKRD) への参加もお願いします！
- オフライン参加の方もいるので、[Zoom](https://us06web.zoom.us/j/89498832308) への参加もお願いします
- [Youtube](https://www.youtube.com/@miraito) のチャンネル登録もぜひ！

## 参加者

### 開催する人
- hiro
- yuki
- takuma
- bucchi
- tomo

### 現地参加する人
- ucan
- suzuki_mar
- yodaka

## 本日の議題

### 戦略的DDDを重要だと思った理由がしりたい （suzuki_mar

- 戦術的DDDから始めがちだけど、みんなどのタイミングで戦略的DDDに切り替えてる？
- 戦略なしでドメイン作れるの？
- 戦術DDDだけを行うことは軽量DDDと呼ばれてる
- 戦術的DDDは1つのアプリケーションを具体的にどう実装するかというテクニックの話
- この本を読んだよ
- https://www.amazon.co.jp/実践ドメイン駆動設計-ヴァーン・ヴァーノン-ebook/dp/B00UX9VJGW
- https://codezine.jp/article/corner/655
- ドメイン駆動設計をやろうと思ったら、戦略設計無しで始めるのは無理じゃない？
- 分析モデルと実装モデルは必要だよね
- ドメインモデルをコードに落とし込むためには戦略的設計が必要不可欠

### 取得時のドメインロジックをどう表現するか知りたい（yodaka
- マルチテナントとは
- SaaSやASPサービスなどのように、同一のシステムやサービスを、無関係な複数のユーザー（企業や個人）で共有するモデルを指します
- DDDってリポジトリで登録処理については知見をよく見かけるが参照はどうするべき
- 参照に特化したものならQueryサービスを使う
- 参照だけならドメインのロジックは持たせない方がいいんじゃない？
- 権限次第で取得可否を判断する処理をドメインとして扱う？
- 参照自体にドメインロジックが必要な場合はどう表現するのがいいんだろ
- ドメインサービスを使う
- DBの事を考えるとDB都合でドメインモデルやリポジトリのインターフェイスが歪んでしまうからテーブルの設計は工程の終盤の方にするようにしてる
- システムを新しく設計する時にテーブル設計から入ってしまう事が多いからDDDを始めるときにDB設計に引きづられがちになるよね
- 詳細は後回しにするとわかってても難しい

### みんなはどうやって DDD を勉強してきたか聞きたい (bucchi
- Learning Domain-Driven Designという本を読んだ（suzuki_mar
- 問題文を見てみんなで議論したりした
- https://www.amazon.co.jp/Learning-Domain-driven-Design-Aligning-Architecture/dp/1098100131
- DDDを導入したいという話があって、みんなで勉強しながらやった

- 増田さんのツイッターをフォローしました！
- ミライトデザインでは社内勉強会で週一ペースで勉強しました
- 成瀬さんのDDD本
- codezine
- [IDDD本から理解するドメイン駆動設計](https://codezine.jp/article/corner/655)
- 成瀬さんのDDD本を読んだ（yodaka
- DDDを導入するのはコストがかかるから、スタートアップの案件とかではなかなか採用しにくいかも
- 成瀬さんのDDD本を読んだ（ucan
- 本の中からわからないことは松岡さんのgitを漁った
- issueを見た
- 質問箱を見た

### DDDを導入するとどういうメリットを感じたか知りたい （ucan
DDDでやっていて良かったことが知りたい！（takuma
業務の知識（ドメイン）をコードに落とし込んだことで良かった事が知りたい （yuki

- モデリングしてからDB設計をする習慣がついた
- わかりやすく感じたメリット
- 動くものを作る時にどう書いていけばいいのかを考える指針ができた
- 機能単体は実装できるけど、業務と関連づけるためにはどうすればいいのがかわかるようになった
- 業務に関わる人と一緒にモデリングをしているため、成果物の認識がずれにくくなった
- 機能を実装する時に業務にあったものが出来ているのかを判断できるようになった
- テストしやすいモジュール分割ができるようになった
- オブジェクト指向しか勉強していない時は特定のオブジェクトにどこまでロジックをもたせればいいかわからかった
- DDDを勉強してからどのオブジェクトにどのロジックをもたせるか判断できるようになった

### そこそこの規模でがっつりトランザクションスクリプトな既存プロダクトに部分的にDDDを導入することは難しいでしょうか？ （みずはし

- トランザクションスクリプトな既存プロダクトってどういうものか
- 手続き型で実装している
- 既存コードがあると2重管理になってしまうから難しいよね
- 例えば特定の集約をある部分でしか使ってないのに、他の部分では使っていないとかになるとドメイン設計のメリットは出しにくいかも
- 新しく実装する機能とかであれば部分的に導入はできそう
- 既存のシステムに依存しないのであれば部分的導入はできそう

- ちょっとずつ導入して最終的にDDDに持っていくって意味でなら良いと思います
- 業務の核となるところからやっていくとか
- 手続き型で実装されているなら、DDDを導入するより先にテストしやすいコード置き換えた方が費用帯効果高そう

### みんながドメイン駆動設計ってどういうものと捉えているか知りたい（hiro
- クラスやメソッドの振る舞いを表現できる設計（ucan
- コアなロジックを分離しよう（takuma
- ドメインの知識と一緒に成長していける設計（yuki
- コードを見れば業務ロジックがわかる設計（tomo
- コードと実務をつなげるための設計（bucchi
- ビジネスサイドとプロダクトを成長させるための設計（suzuki_mar
- 業務知識をコードに落としこむための設計（yodaka

- hiroさんが聞きたかったのはどういう事をすればドメイン駆動設計だよっていうのが知りたかった
- ビジネスサイドと一緒にコミュニケーションをとりながら開発をしているか
- 開発者だけでやっていたらドメイン駆動設計ではないかもしれないね。軽量DDDかな
- ドメインモデルがFWに依存していない

### DDDを導入する際に苦労したこと・導入して良いと感じたことが知りたい (tomo

## 資料

### 勉強会のお知らせ
株式会社askenさんで開催する勉強会に登壇します
[エンジニア勉強会開催のお知らせ―ドメイン駆動設計（DDD）の始め方](https://www.asken.inc/news/2023/8/31/ddd)

ペチオブ
[クラウドサービス開発の肝はサービス横断の機能開発](https://phper-oop.connpass.com/event/295106/)

## アンケートのご記入をお願いします！！

今後の参考にしたいので [こちら](https://www.noway-form.com/ja/f/afaf2623-3b77-4d73-9293-79ca14938511) からアンケートの記入をお願いします！！