# ボトムアップドメイン駆動設計

## 9章「ファクトリ」

19:30:39	 開始 鈴木/脱脂綿/司会 : 9章　ファクトリ
19:36:02	 開始 鈴木/脱脂綿/司会 : 自動採番ありきなのは分かる
19:36:46	 開始 鈴木/脱脂綿/司会 : 識別子無いと意図しない動作→その設計が悪い？　意見交換しどきポイントかもしれない。
19:38:53	 開始 鈴木/脱脂綿/司会 : ファクトリはクラスに限らない
19:39:29	 開始 Masayuki Abe : やはりドメインモデルがいかに自然に思えるかが重要なのかなぁ。
19:40:19	 開始 鈴木/脱脂綿/司会 : コンストラクタ内で他のオブジェクトを生成するかどうかで、ファクトリを採用するかどうか判断
19:40:21	 開始 Katsuhiko Terada : 責務のスコープをどう考えるか

### 感想

### 疑問点
- 「識別子無いと意図しない動作→その設計が悪い？」の部分もうちょい聞きたいです
- 識別子無いと詰むケースなんてそんなにある？（識別子無いタイミング=作られた時点という場合に）
- 集約などで識別子以外で関連を示せればいいはず
- 疎結合にするために識別子がないと通信できない設計にしている場合
- 永続化のタイミングでいい vs 付けるとしたら作成時
- 識別子の目的は永続化ではない
- 識別子はドメインの知識ではないはず
- メールアドレスのようなものならドメイン知識だが
- 識別子はドメインの知識をあらわすべき、っていう考えもあります（過激派な感じしますが）
- Nullable制約をつけるなら、idだけNullableなのは気持ち悪い
- Entityが識別子持ってないタイミングある、って気持ち悪い
- Entityのライフサイクルの問題で許容されてない
- いつ誰がidを採番するのかわからない→使えない
- ルールが明確であれば使える
- 概ね皆オブジェクト生成時につけるルールになってるはずでは
- つけてないと損する、つけといて損はない

## 10章「データの整合性を保つ」

19:40:55	 開始 Katsuhiko Terada : グラレコ！
19:41:13	 開始 Masaki Kanno ( 神 ) : 10章 データの整合性を保つ
19:43:12	 開始 Masaki Kanno ( 神 ) : ドメインルールがコードに現れないのが問題
19:44:52	 開始 Katsuhiko Terada : これはDDDなのか？
19:45:31	 開始 Masaki Kanno ( 神 ) : ユニットオブワークはファイルのメモリキャッシュの概念みたいだ
19:45:39	 開始 Katsuhiko Terada : そこですね

### 感想

### 疑問点

## 11章「アプリケーションを1から組み立てる」

19:46:41	 開始 鈴木/脱脂綿/司会 : 11章　アプリケーションを1から組み立てる
19:57:06	 開始 Masaki Kanno ( 神 ) : ユーザー数上限はドメインオブジェクトに書くんじゃないのか？
19:58:12	 開始 Masaki Kanno ( 神 ) : ↑ちゃんと補足された

### 感想
- 総復習だった

### 疑問点

## 12章「集約」

19:59:23	 開始 Masaki Kanno ( 神 ) : 12章 集約
20:01:30	 開始 Masayuki Abe : でてきた
20:02:38	 開始 Masaki Kanno ( 神 ) : 永続化する際にアクセスできないのは厳しいな、手軽にやりたい
20:03:45	 開始 Masayuki Abe : スマホアプリとかだとNotificationとか端末の通知に思えちゃうから、使うなら名前考えないとだな。。混乱しそう
20:05:05	 開始 Masayuki Abe : 集約の単位、他の区切り方何があるかきになる。

### 感想
- 集約の単位は悩む。雑な区切り方されてることも多い印象。

### 疑問点

- CQRS
- 実際デメテルの法則に厳密に沿って通知オブジェクト作ってる所あるんですかね？？？

## 13章「仕様」

20:07:12	 開始 鈴木/脱脂綿/司会 : 13章　仕様
20:07:30	 開始 Masayuki Abe : なんて仕様だ
20:08:20	 開始 Shin Ohno : isSatisfiedBy は、サーバプログラム書いていたときいくつか使ってはいたけど、浸透はしなかった。。
20:09:06	 開始 Masaki Kanno ( 神 ) : なるほど、仕様オブジェクトか
20:09:29	 開始 Masaki Kanno ( 神 ) : でも、ドメインサービスでもいい気がするなあ
20:09:39	 開始 鈴木/脱脂綿/司会 : 仕様オブジェクト、ドメインサービスと何が違う？
20:09:41	 開始 鈴木/脱脂綿/司会 : 言われてた
20:10:03	 開始 Shin Ohno : 条件しかないですね。Specification Pattern は。 isSatisfiedBy のみ
20:10:51	 開始 鈴木/脱脂綿/司会 : 何をするのかというより、どういった状態であるかを判別するということかな？
20:12:26	 開始 Masayuki Abe : Usersみたいなファーストクラスコレクションを使ったことがあるけど、プルリク で弾かれた
20:17:30	 開始 Masaki Kanno ( 神 ) : 全件とってくるのはパフォーマンス的にどうなんだ
20:17:52	 開始 鈴木/脱脂綿/司会 : 神さんの疑問めっちゃ拾われますねｗ
20:18:46	 開始 Shin Ohno : Criteria Pattern?
20:19:19	 開始 鈴木/脱脂綿/司会 : ↑後でそれ詳しく教えてほしいです！（初耳
20:19:21	 開始 Masaki Kanno ( 神 ) : CQRS でもでてくるやつ＞リードモデル
20:20:14	 開始 鈴木/脱脂綿/司会 : 要はバランス

### 感想

### 疑問点
- Criteria Pattern初見なんで知りたい
- https://www.tutorialspoint.com/design_pattern/filter_pattern.htm
- CQRSってなんでしょうか
- Command and Query Responsibility Segregation
- 更新処理と参照処理を異なるオブジェクトにしましょう、みたいな概念
- >Usersみたいなファーストクラスコレクションを使ったことがあるけど なぜなんだろう？
- レビュアー
- 命名「Usr」「Usrs」が分からん
- 今ここでこのクラス作る必要ないよね
- ファーストクラスコレクションが持つオブジェクトはコピーなのか参照なのか？
- コピーであればパフォーマンス、ライフサイクルに問題ありそう
- 参照であればライフサイクルは気にしないといけないが使えそう？
- 集約の中ならライフサイクルは知っているのでは
- 「現場で役立つシステム設計の原則」参照！

## 14章「アーキテクチャ」

20:20:54	 開始 Masaki Kanno ( 神 ) : 14章 アーキテクチャ
20:21:36	 開始 y_watanabe : はじめ、DDD = clean architecture だと思ってました
20:22:24	 開始 鈴木/脱脂綿/司会 : 「ドメインを捉え、うまく表現する」に集中したい
20:23:49	 開始 Shin Ohno : オニオンアーキテクチャというのもあってな。クリーンアーキテクチャとヘキサゴナルアーキテクチャと、ほとんど同じ認識
20:24:17	 開始 鈴木/脱脂綿/司会 : https://qiita.com/little_hand_s/items/ebb4284afeea0e8cc752
20:24:28	 開始 鈴木/脱脂綿/司会 : そうですね！
20:26:21	 開始 Shin Ohno : https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html Though these architectures all vary somewhat in their details, they are very similar. They all have the same objective, which is the separation of concerns. They all achieve this separation by dividing the software into layers. Each has at least one layer for business rules, and another for interfaces.
20:31:48	 開始 鈴木/脱脂綿/司会 : WebフレームワークでControllerを置き換え可能に思ったことないけど、本来あるべきは可能にすることなんだろうな
20:32:02	 開始 Katsuhiko Terada : 大野さんだけにとんでしまった
20:32:21	 開始 Shin Ohno : w
20:32:23	 開始 鈴木/脱脂綿/司会 : あら
20:32:29	 開始 鈴木/脱脂綿/司会 : そういうこともあります
20:32:32	 開始 Shin Ohno : Katsuhiko Terada から自分:(プライベート) (08:31 午後)

アダプターパターンはありますよね
20:32:52	 開始 Katsuhiko Terada : そこ
20:33:02	 開始 Katsuhiko Terada : アダプターは、依存性逆転
20:33:34	 開始 鈴木/脱脂綿/司会 : DIPだけ先に聞いててわけわからんって思ってましたけど、アーキテクチャを学んでから腑に落ちました
20:33:46	 開始 Shin Ohno : WebフレームワークでControllerは、基本 Web の UI なので具体的なもなイメージ。取替可能なものは、コマンドから受け取る入出力とか
20:35:48	 開始 Masaki Kanno ( 神 ) : バッチ処理を Web からも CLI からも叩けるようにしたとき、 Controller 取替可能が実感できた
20:36:09	 開始 鈴木/脱脂綿/司会 : ↑なるほど

### 感想

- オニオンアーキテクチャーの再確認で、よくわかっていなかったことが分かった（DDDと関係なかったけど）
- この本はクリーンアーキテクチャな気がする

### 疑問点
- この辺のアーキテクチャ踏襲した FW あってもおかしくないのに流行ってない気がする
- ↑それ

## 15章「ドメイン駆動設計のとびらを開こう」

20:37:01	 開始 Masaki Kanno ( 神 ) : 15章 ドメイン駆動設計のとびらを開こう
20:37:33	 開始 y_watanabe : 耳が痛い話…
20:37:42	 開始 鈴木/脱脂綿/司会 : FW手に入れたらFWで全部殴りたく鳴る
20:38:07	 開始 鈴木/脱脂綿/司会 : 全部をトンカチで殴りたくなってるの今の私かも...
20:39:05	 開始 鈴木/脱脂綿/司会 : ドメインエキスパートが理解を放棄する
20:39:15	 開始 鈴木/脱脂綿/司会 : エンジニアはいつもわけわからん言葉でしゃべる」
20:40:02	 開始 Masayuki Abe : 両方一人でできたら最強じゃねぇか！
20:40:07	 開始 鈴木/脱脂綿/司会 : １？ｗ
20:40:24	 開始 Masaki Kanno ( 神 ) : つ「個人開発」
20:40:39	 開始 y_watanabe : https://note.com/nerd0geek1/n/n7b72fdf7c42d
20:40:42	 開始 Shin Ohno : ドメインエキスパートが開発者と違うことは、良くないと言っているケース結構あるよ
20:41:03	 開始 Masayuki Abe : 沼。。
20:41:45	 開始 鈴木/脱脂綿/司会 : 開発者がドメインエキスパートになると、つぶしが効かなくなってエンジニアとしては嫌がりそうなイメージがありました
20:42:17	 開始 鈴木/脱脂綿/司会 : とはいえ全く業務知識ないまま開発なんてできないので、またここでもバランスの問題
20:42:50	 開始 Masaki Kanno ( 神 ) : 最初は分からなくても、ドメインエキスパートと対話するうちにエンジニアもドメインエキスパートに近くなってくる、と思う
20:42:58	 開始 Katsuhiko Terada : ですね。
20:43:18	 開始 鈴木/脱脂綿/司会 : なるほど
20:43:34	 開始 Masaki Kanno ( 神 ) : おれ、ドメインエキスパートじゃないし、みたいな態度だとうまくいかないでしょうね
20:43:50	 開始 Katsuhiko Terada : ユビキタス言語の実体は？
20:44:46	 開始 Masaki Kanno ( 神 ) : ユビキタス言語に実態をもたせたかったら用語集とかになると思う
20:45:18	 開始 鈴木/脱脂綿/司会 : ドキュメントとかソースコード、成果物をユビキタス言語で書いていこうということなのだと思ってます
20:45:46	 開始 Katsuhiko Terada : エンティティ
20:47:25	 開始 Masaki Kanno ( 神 ) : コンテキスト単位でパッケージ分けるんかな
20:48:38	 開始 Katsuhiko Terada : メタスクラム
20:49:45	 開始 Masaki Kanno ( 神 ) : コードからドメインへのフィードバックも大事ね
20:49:51	 開始 Katsuhiko Terada : 15章が一番DDDっぽい
20:51:00	 開始 Katsuhiko Terada : 酒もってこよー
20:51:17	 開始 Shin Ohno : 帰宅するので、再開できないかも。
20:51:27	 開始 y_watanabe : お疲れ様でしたー！
20:51:41	 開始 Masayuki Abe : お疲れ様でしたー
20:52:20	 開始 鈴木/脱脂綿/司会 : 承知しました！　無理せずですが簡単に感想など書き置きいただけるとトピック膨らませておきます！
20:53:56	 開始 Masaki Kanno ( 神 ) : 僕も一旦帰るか悩んだ、というか腹減った、ラーメン食べたい

### 感想

- ここがDDDっぽいってのは確かにと思った。コードだけじゃない。
- ここからエヴァンズ本へってことなんですよね

### 疑問点

## チェックアウト

### あべさん
知らないこといっぱいあった。仕様とか集約については勉強になる所多い。
Clean Architectureについても勉強になった。
原著（エヴァンズ本）もチャレンジしていきたい。

### てらださん
知らない言葉がぴょこぴょこ出てて調べて読んだので、勉強になった。
オニオンアーキテクチャ、理解してたつもりで思ってたよりもっと深かった。
エヴァンズ本やるのか、これやるのか！？

### 鈴木/脱脂綿
エヴァンズ本やりますよ！ 覚悟はできてます。
本読んだ上の知識は持ってるが、実践経験ないので皆さんの経験仕入れられてよかった。

## しゅん
最初はコードばっかりだなと思ってたけど、15章でこれわざとかと気付いた。
エヴァンズ本は「なんだこりゃ」から押し流される本っていう印象。
前知識あることで理解しやすくなるかも。
「あるひとりの開発者の物語」...オブラートに包んだいい表現だな。
「技術書ではない」「読む人によって解釈が変わる」ので、何人かで同じところ読んで解釈をぶつけ合うといい。
mohikanzで輪読会やった際、週1だと半年掛けてしまった。

## 神
全部の実践はしたことないけど、過去の勉強で大体知ってたが、仕様は初見だった。
「オレオレDDD」やりたくなってるのをどうやって抑えるか悩んでいる。
「軽量DDD云々」はアジャイルとスクラムの話に似ている気がする。
軽量DDDは、実際にDDDでやりたいことをどう実装するのかのパターン。
スクラムはFW、アジャイルは思想。
頭では理解しつつ無視してえなあ。