DDD本 5章：ソフトウェアで表現されたモデル
===
###### tags: `エヴァンス本読書会`

# Discord開始位置

- https://discordapp.com/channels/432531367427964929/740202765619429487/769484533749121074

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントやリアクションでどんどん参加してください！ラジオ担当が拾っていきます。
- 聞いているだけの方もOKです！

# ディスカッションをより豊かにするためのグランドルール

- 参加者は毎回任意
- 今回は不参加、次回は参加をするといった気軽な感じ
- 途中参加も断然OK! まずは聞くだけでも大丈夫です！
- フィードバックを恐れない
- マサカリは怖いと思いますが、アウトプットからのフィードバックを受け、学びを深めていきましょう
- アウトプット7割：インプット3割の気持ちで臨みましょう！
- 経験の有る無しは気にしない
- 自分はDDD非経験者だから……と気後れする必要はないです
- 堂々と意見や疑問を語りましょう
- ページ数と同時に、節のタイトルやキーワードを言って頂けるとスムーズです
- 電子書籍で読んでいるとページ数ではわからないため
- 話していない人が、率先してメモしましょう
- このHackMDはみんなのものです。どんどん書いていきましょう:+1: :+1:
- 気になる質問や同感するものには :+1: を末尾につけてください。

# タイムテーブル

| 時間 | 所要時間 | 内容 |備考 |
| -------- | -------- | -------- | -------- |
| 19:50- | - | 集合開始 | |
| 20:00-20:15 | 15分 | 当日の流れとグランドルールの共有 | |
| 20:15-20:25 | 10分 | 感想記入&HackMDに書かれた皆さんの感想・気づき・疑問をもっと掘り下げたいものを、 :+1: 付けていく | |
| 20:25-21:55 | 90分 | 本の節ごとにディスカッション（ここでも適宜、HackMDに気づきとか書いていってもらっていいです） | |
|21:55-22:00 | 5分 | 次回開催日と読む範囲決めてクローズ | |

## 下に感想などを書いていって下さい。どんな些細なことでもOKです。

---

# 第5章 序章
## 目安の時間
- 22分

## 感想・気づき
- 読み返して、「モデルとは関連性の設計から始まる」と書いてあるのにふと気づいて、そうだよな！と納得しました
- 参照オブジェクトとか値オブジェクトみたいな「データの持ち方」が割とDDDって話題に上がること多いですけど、まず関連から入るってのは、自分が設計するときを考えてもそうだよな、という納得感があります。 :+1::+1: :+1::+1::+1:
- :memo: （例えば）クラス図は、個々のクラスより矢印や線に注意する派
- :memo: 自分はモデリングは、主要な概念を見つけて、それらの概念間の関連を見つけて、それを増やしながらぐるぐるやって、ってやりますね。
- :memo: ソフトウェアモデリングに限らず、モノコトの重要な部分や複雑さは、個々のモノコトではなくモノコトの間にあると思う、的なアレ
- モノコトの間にインタラクションがあるので同意。関連を見つけるために、その前提となる概念を探すという感じですね。
- アクション的な要素をサービスクラスに出すのって、もうちょっと進むと関数型パラダイムにもなりそうですよね（厳密にデータ型定義して、それを操作する関数で表現する）
- P.79「あるオブジェクトは...連続性と一意性を持ったものを表現しているのか？それとも、他の何かの状態を記述する属性なのか？これがエンティティと値オブジェクトとの基本的な区別である。」これだけは理解できた。他の説明は抽象的で難しかったです（DDD初学者）:+1::+1::+1::+1::+1:
- P.80の関連の節で、2つのオブジェクト間をコレクションで表現したり、Setで表現したりするのは簡単だけど、双方向の関連性を持たせるのは、概念的にも複雑になりやすいし、実装でも複雑になるんだろうなぁと思っていた:+1:
- > サービスとは、要求に応じてクライアントのために行われる何かである。
- 「サービス」って言葉は色んな所で色んな意味で使われるので、定義されているのは重要だなと思いました（エンティティとかモデルとかが界隈によって異なる意味を持つみたいな話）:+1::+1::+1::+1::+1::+1::+1::+1:
- :memo: ドメインサービスのことだと思う
- :memo: p.105 では、アプリケーションサービスとドメインサービスが両方でてきてますね
- やっぱり静的型付け言語じゃないとやりづらいな～と思った(雑):+1::+1:

## 疑問
- [GOOS本](https://amzn.to/3mim5s3)とかでは、「オブジェクト指向はメッセージングにより結び付けられる」的な捉え方がなされていますが、「メッセージング ≒ 関連」と思っていていいのかな
- そうだとすると、かなり同じことをGOOSとDDDは言っている気がします
- オブジェクト指向とは? :thinking_face:
- 「オブジェクト指向はもはや『プログラミング一般』に概念として取り込まれてしまっているので、殊更に取り上げるトピックではない」という旨の意見を見たことはあります
- P.84で登場するSQLを使用したエンティティは、入出力と密結合していて嫌な感じがするが、あくまで例として捉えればいいだろうか
- P.85で「実際のプロジェクトにとっては、必ずしもよい設計とは限らない」とありますね
- コードを伴う具体的な設計手法の話になってきましたが、皆さんが普段使われている言語やフレームワークを聞いてみたいなと思いました。どういった言語でDDDを実践されているのか。 :+1: :+1: :+1:
- 現状はJava or Kotolin/ Springboot / Doma が多いですね。
- Ruby, Scala, Java 辺り
- :memo: アンケート
- Rust: 1
- Java: 9
- Kotolin: 1
- Ruby: 4
- Scala: 3
- C#: 10
- Python: 3
- Excel VBA: 1
- PHP: 2
- C++: 3
- go: 2
- TypeScript: 3
- Ruby on Rails: 3

---

# 関連
## 目安の時間
- 22分

## 感想・気づき
- p.81 「ドメインを理解することで、本来はどちらの方向性が重要であるのかが、明らかになる場合がある」という点が深いです。言い換えると「実装者がビジネスロジックそのものの本質を理解しないと、変更容易なプログラムを書くことはできない」ということだと思うので、古来からの上流と下流が物理的に分離する開発手法では良いものは出来ないってことですよね。:+1:
- :memo: 現実世界の関連は多くの場合n-nだけど、それをそのままソフトウェアに持ち込むのでなく今作ろうとしているソフトウェアにとって本当に重要な関連はどんな形なんだっけ？を吟味しよう、それはドメイン理解によって得られることがあるよ、ということかなと。:+1::+1:
- ドメインの知識（≠現実の写像）をソフトウェア設計にも反映しましょう、というお話し（＝モデル駆動設計を支えるプラクティスの一例）であって、変更容易性のお話しはしてない気がします
- 上流-下流といったモデリングあるいは設計プロセスのお話しも、ここではしていないような:+1:
- 同じくp.81より
- > 「現実の世界では、多対多の関連がたくさんあり、その多くは元々双方向である。（略）だが、これらの一般的な関連のせいで、実装と保守が複雑になってしまう。しかも、こうした一般的な関連は、そこにある関係の性質について、何も伝えないのだ」
- > 「アプリケーションの要件が双方向にたどることを求めないなら、一方向にだけ辿るようにすることで、相互依存関係が減り、設計がシンプルになる」
- P81 「関連を辿る特定の仕組みを設計で定義し、モデル内にある関連とふるまいを一致させなければならない」の直前に書いてある説明で、関連を考える場合にオブジェクトの持ち方を気にする必要はないということかと思った。どうしても、データベース設計っぽく考えてしまうことがあるので。
- モデリングをしようってなったときに、どうしてもDBのエンティティっぽくなってしまって、「エンティティ＝データの入れ物」ではなく、同一性とか同じ属性の値を持っていても、ちゃんと区別したいものベースで考えないと駄目だなぁと感じた:+1::+1::+1:

## 疑問
- この書き方ってあまりしないなーと思いました。UML的にはこういうのあるんですっけ？ :+1: :+1:
- メソッドを通じて一つに限定して取る、というのは確かに既存のクラス図だと明示的に書きづらいですね
- :memo: 「[限定子](https://www.ogis-ri.co.jp/otc/hiroba/technical/JavaWorld_UMLIntroduction/index.html)」という関連端を修飾する記法で、特定の属性を検索条件として決定される関連を明示するためのもの
- 皆さん既存ソフトの複雑な関連を発見したらどういうアプローチをされますか？ :+1::+1::+1::+1:
- 参考までに私がよくやるのは以下みたいな感じです
- まず双方向関連をすべて取り除く
- インタフェース参照などで依存性を逆転させて片方向にしていく
- 巨大な参照ハブとなっているオブジェクトを分離できないか考える
- :memo: 触らなくてもいいなら触らない
- 触れる日が来るまで、概念だけ整理して合意を取る...
- :memo: 腐敗防止層にしちゃうのはありですよね
- :memo: 「新実装領域」をつくって「ちょっとずつピックアップしてDDD世界を作る」かな（言い換えてるだけだけどｗ
- :memo: 複雑な入出力をまず追い出したい
- :memo: 改善しないとっていう場合には、 その関連を分類して、関連間の関連を整理して、それごとにわかるようにリファクタリングして、最終的には別クラスに分離できないかなども考える。 その過程で責務が整理され始めたら、モデリングし直して、作り直すことも考える。
- 関連が複雑に絡み合いすぎていると言うことは、そのクラスに複数の責務が混在しているので、その責務ごとに関連を分類していく感じです。
- :memo: 双方向関連？神クラス？
- 一つの責務が分散してしまっていると複雑化しますね。
- :memo: 改めてモデリングして、それに基づいて設計・実装したあと、 一枚層を噛ませてから部分的に交換、みたいなのはちょっと前にやりました 既存の生データ構造にゴリゴリ依存したオブジェクトを受け取って、 ドメインオブジェクトに変換してから改めて設計・実装した方に送るてきな層
- だいたい腐敗防止層と同じイメージですー
- :memo: レガシーコード改善ガイドを読みましょう
- クラス図に便乗質問なのですが、クラス図でValueObjectとエンティティって書き分けていますか？特にPlantUMLで・・ :+1::+1::+1::+1::+1:
- ステレオタイプ `<<VO>>`, `<<Entity>>` を入れる
- 書かない派と、ライフサイクルが違うので書く派がいる
---

# エンティティ（ENTITIES） （別名　参照オブジェクト（REFERENCE OBJECTS））
## 目安の時間
- 22分

## 感想・気づき
- P.89「モデル中のすべてのオブジェクトが、意味のある同一性を持ったエンティティであるとは限らない。この問題を複雑にしているのは、オブジェクト指向言語が、あらゆるオブジェクトに同一性の演算を組み込んでいるという事実である」という記述を見て、なるほどと思った。:+1:
- P.91の自由席のイベントの例の場合は、エンティティとして座席番号とチケットとして管理しないというのはわかったけど、その場合は値オブジェクトとして定義するのだろうか
- そもそも総座席数だけで管理したいのであれば、自由席という概念も不要なのかもしれない
- P.91の最後「その上で、ふるまいと属性を、コアとなるエンティティに関連した他のオブジェクトへ移動できないか調べること……同一性の問題を克服すると、エンティティは、所有するオブジェクトの操作を調整することによって責務を果たすようになる」
- エンティティは同一性を担保することが目的であって、なるべく他のオブジェクトへ移動して振る舞いを移譲し、調整するという感覚がなかったので、なるほど、と思った
- P.92の図5.5「同一性と関連した属性は、そのエンティティと一緒に留まる」の説明を読んでそのエンティティに留めるか、別のオブジェクトへ移動するかの判断基準がわかったのが大きい :+1::+1::+1::+1::+1::+1::+1:
- 「同一性のための操作を設計する」の項の「同一性を定義するには、ドメインを理解しなければならない」という箇所を読んで、普段開発してるときautoincrementで採番されたIDやUUIDを深く考えずに識別子としまってるけど、モデルがすでに持っている値からそのドメインでは同一であるとみなせる場合にはそれを使った方が良いのかな、良いのだろうな、と思った:+1:
- それ自体には賛成なのですが、IDでしか引けない事がほとんどと思いますよ（メアドもある意味IDとして使っている場合多いでしょうし）
- むしろ「同じIDをもつ」というのはどういうことかの考察が重要なのではないでしょうか。:+1: :+1: :+1::+1::+1::+1:
- それは更新で表現すべきなのか、新たなIDを採番し元のものを削除すべきなのか、というのは結構頭を悩まさせられる問題に思います
- :memo: 「IDぽいのは同じで、フィールド値が違う、けれど比較される」ってことって、ようあります？
- :memo: 「同一IDで内容比較」はあるけど「IDで同一性を見る」は、あまり出会ってない…から聞いてみました。
- :memo: この感想は、DB用語で言う、ナチュラルキーとサロゲートキーのどっちがいいか問題、みたいなアレ?
- :memo: IDの値を分解して解釈する必要があるようなIDはアレ
- :memo: ナチュラルキーでもいいのだけれど、その内部構造を持っているような場合とかはだめだし、後々の運用でIDを変えるとか、可変に化けてしまうケースがあるので、その懸念があるならば意味のない値をIDとしたい。
- これを判断するには、「ドメインを理解しなければならない」
- 分散システムで同一性を担保するパターン集があれば、知りたいと思った
- 「同一性が重要なのはシステムのコンテキスト内だけ」とあるので、気にしなくていいのかな？
- p.87 *「多くのオブジェクトは、本質的に、その属性によってではなく、連続性と同一性によって定義される」*
- 「同一性」だけでなく、「連続性」という言葉にも注目してみたい:+1:
- 「同一」であるというだけでなく、それは空間や時間を超えてなお「連続」していなくてはならない:+1:
- p.89 *ライフサイクルを通じた連続性を持ち、アプリケーションのユーザにとって重要な区別が属性から独立してなされるものは、すべてエンティティなのだ*
- テセウスの船を連想
- https://ja.wikipedia.org/wiki/%E3%83%86%E3%82%BB%E3%82%A6%E3%82%B9%E3%81%AE%E8%88%B9
- どうしてもエンティティをデータベースのテーブルと紐付けてしまい、なんとなく理解のブレークスルーが起きていない感がある:+1::+1::+1:

## 疑問
- マジでこの「エンティティ」という言葉がDDD学ぶ人を苦しめていると思うんですよね。DB用語の「エンティティ」とごっちゃにしてしまう人が非常に多い印象です。皆さんどう思われます？:+1::+1::+1::+1::+1:
- 前提がDB開発者であればそうかも知れませんね
- むしろ、DB屋の方がDDDのエンティティを正しく理解するように思う
- エンティティを考えるのは実体関連モデルの分析までで、スキーマ設計以降はエンティティという概念は出てこない
- 混乱しているのは、プログラミングにおけるエンティティとの混同の結果で、このエンティティはDB設計文脈でのエンティティとは異なる
- 逆に、DDDを先に学んだ方はDB用語のエンティティに同じ印象を持つと思います:+1:
- エロマンガ島とかスケベニンゲン的な感じ
- いや、DB用語だけじゃなくてEntityって言葉はテーブルのアイテムとして既にいろんなフレームワーク（特にORM）の中に入ってきているので、DB開発者だけが意識する言葉ではないと思うんですよ。ORMでいうところの「Entity」とDDDの「エンティティ」は、おなじになることもありますが意味的にはぜんぜん違うものなので:+1:
- JPAのEntityアノテーション: https://qiita.com/ughirose/items/5d691adc677aa08636b8
- C# の Entityフレームワーク： https://docs.microsoft.com/ja-jp/ef/
- クリーンアーキテクチャも「エンティティ」という言葉使ってますね :bomb: :+1:
- （あれは、単に言葉がガバなだけ感もありつつ）
- 序章で「連続性と一意性を持ったもの」、ここでは「連続性と同一性」、一体どっちなんですか！エヴァンスさん！
- そう思って原著を読むと両方とも「identity」と書いてあるわけで、この本読むとき原著必須なんですよね（絶望）:+1::+1:
- 用語解説には「本質的に、属性によってではなく、連続性と同一性の連なりによって定義されているオブジェクト」と記されているので、どちらも持っている必要があると理解しています。
- あ、ここで気にしているのは「identity」の訳が「一意性」と「同一性」で割れているのを言ってます。結構この翻訳そういうとこあるので。。。
- これはこの説明文を説明するために「同一性」という表現をしていると思います
- 後の文章が比較して同じものである事が書いてあると思います
- 言いたいことは一意性ですが、文章の流れ的には同一性がいいと思ったんじゃないですかね
- 後の文章で困っている気は若干しますが…
- そもそも「同一性」と「一意性」って意味違いません？（なぜ訳語を変えてしまったのだろう……）
- 最初にクリーンアーキテクチャから入ると、さらに悩まされる。:+1:
- P.90「実は二つのオブジェクトを同一であるとみなす上では、同じ属性を持たなくてもよく、必ずしも同一クラスですらなくてもよいのだ。」難しい・・・。顧客のAさんと営業担当のBさんが実は同一人物でした、的な話かな・・・？ひとまず、どうやってその同一性を表すかのルールを、属性やクラスの枠組みにとらわれず洞察せよ、ということと理解。たぶん、ロジックで表現・・・？:+1: :+1: :+1: :+1:
- :memo: 戸籍上のある人物と、あるgoogleアカウントの持ち主と、あるqiitaアカウントの持ち主は、実装は違うが同一、みたいな話では
- :memo: 同一性が同じIDクラスで表現されていて、同じ値になっている物を「同一である」と定義すれば、別クラスであろうとも同一物、みたいな。
- :memo: 同一性が対応付け可能ならば同一物と見做すという定義も追加で成立しますね。
- :memo: ただただその概念にとっての「同一性」によって判断されるのであって、 その「同一性」の基準を満たしているなら、他の値がどうとか、クラス定義がどうかは問わない（実装の詳細ではなく、ひたすら「同一性」にのみ依存んする）、 みたいなイメージ
- :memo: SNSアカウントでログインするような
- :memo: Qiitaアカウントと戸籍を**同時に扱うソフトウェアでは**、同一になるんじゃないでしょうか
- :memo: 'Id'entity!!
- :memo: 一般的な意味での同一性か、あるシステム範囲での同一性か、特定のシステム内での同一性か、とか。議論が混ざり始めたような気がする。
- :memo: 現実の世界のルールではなく、ソフトウェア適用対象のドメインにおけるルールによるのでは
- リモートオブジェクトをローカルでキャッシュする技術的なフレームワーク
- リモートオブジェクトってなんだろ？ どのようなフレームワークが、該当するのか気になった
- 最近Realm触りましたがまさにそんな感じでしたよ（フロント向けですけどこれは）
- もしかするとGitを思い浮かべるといいのかも

---

# 値オブジェクト（VALUE OBJECTS）
## 目安の時間
- 22分

## 感想・気づき

- 子供のお絵かきエピソードの話、わかりやすい:+1:
- P.97の「概念的な統一体」を形成すべきである
- [Whole Value](https://sundin.github.io/patterns/2018/10/04/whole-value-pattern.html)

## 疑問
- C#に限った話かもしれませんが、[More Effective C#](https://www.shoeisha.co.jp/book/detail/9784798153988)には「値オブジェクトは構造体(struct)で定義しましょう」という記述があります。確かに構造体は、値比較できるため概念的には値オブジェクトの定義には適していると思います。しかし、C#の構造体は「必ず引数なしコンストラクタが実装される」という言語仕様があるため、意図せず引数なしコンストラクタで生成されたことを考慮して、nullオブジェクト的なもの等の用意が逐次必要になってきます。（例えば住所という値オブジェクトを構造体で定義する場合、内部の都道府県名や市町村名といったstringはnullになりえないので、引数なしコンストラクタで生成した場合はnullオブジェクトとして扱わないといけない）
- この辺、C#でDDDを実装されたことがある方はどうされていますか？値オブジェクトであってもクラスで定義されますでしょうか？その場合は `bool Equal(object)` をオーバーライドする際は内部のフィールドやプロパティを全て比較するように実装するのでしょうか？
- "フィールドやプロパティを全て比較する" かどうかは場合によるとして `IEquatable<T>` を実装するのかなと思ってます。
- `Entity` や `ValueObject` 的なBaseクラスを作っています。
- この本を読んでいないので推測になりますが、`クラスは参照型`で、`構造体は値型`です:+1:
- エンティティは同一性が重要なポイントなので、クローンを作成すべきでない
- 値オブジェクトは属性の一致性が重要なのでクローンされるべき
- [Microsoft Docs](https://docs.microsoft.com/ja-jp/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/implement-value-objects#value-object-implementation-in-c)では、クラスで定義しているみたいですね。
- `bool Equal(object)` をオーバーライドして、内部のプロパティ比較で問題ないと思います
- 以前C#でやったときは、属性とメタプロ駆使して値型っぽい制限を導入していた気がします（自分が技術リードでなかったので曖昧な記憶 & 多分もう10年くらい前）
- 上記MSのDocsと成瀬さんの本をもとにC#で値オブジェクト実装しました。値オブジェクトもクラス使用しました。
- :memo: 値オブジェクトって概念けっこう理解できない人多い印象なんだけどそうでもないんだね。
- :memo: 値オブジェクトがどんなコードになるかはわかる（その意味である種の”理解”はできる）けど、 それで何が嬉しいの？（string や int じゃだめなの？）というケースが多いイメージ
- :memo: イミュータビリティの意義とかをどこまで理解できるかじゃないですかね
- :memo: 俺の印象では、「値」が「オブジェクト」ってなに？ ってなる人が多い。普通の「イミュータブルなオブジェクトと」何が違うの？ ってなる印象。
- :memo: これが説明できないとイミュータブルなオブジェクト」 = 「値オブジェクト」となってしまう気がする。
- :memo: 可変か不変かではなく、同一性の方が区別の基準なので、後者に着目して理解してほしい。
- :memo: https://sundin.github.io/patterns/2018/10/04/whole-value-pattern.html
- :memo: 「意味付けのため、値に型を与えた」ってか、うーん、言語化能力向上したい！
- :memo: 値オブジェクトの特徴は、「値オブジェクト」とはどういうものか？を考えるのではなくて、 値をオブジェクトで表現したいので、「値とはどういうものか？」を考えた結果が特徴となるものですね。
- :memo: ちなみに値オブジェクトにとって「全てのプロパティが同一であれば同一とみなす」は正なんですかね？
- :memo: 「値として意味のある全てのプロパティが同一」ですかねぇ。
- :memo: 実装上、値としては意味がないけれど、そのオブジェクトの管理で使っているプロパティを持っている、みたいなことはありえるかもしれません。(普通はやらないけれど)
- :memo: 生成時間をprivateメンバで持っているVOとか、同一と言えるのか。
- :memo: generateTimeとか一致しなくていいですからねえ
- :memo: 厳密なルールつくっちゃうと「じゃないから、クラス化しない」とかでてきそうで…「適切にやろうぜ」が…うーん、でもちゃんと考えとくべきかｗ（今日は自分に置き換えて迷いまくりw
- :memo: ソフトウェアを適用する対象領域を我々（開発者以外も含む、人間）がどのように認識するかによると思うので、一律に「○○が値である」と語るのは厳しいのでは

---
---
---

# ★★★【後半(2020/11/07) はここから】★★★

# Discord開始位置

- https://discordapp.com/channels/432531367427964929/740202765619429487/774464053212479488

# サービス（SERVICES)
## 目安の時間
- 30分

## 感想・気づき
- アプリケーション/ドメイン/インフラストラクチャといった層の概念ってここまでですでに説明されてましたっけ？（すみません、発見することができず）
- :memo: 第4章、P.68のレイヤ化アーキテクチャの話がされているので、そこで表形式で各レイヤの責務の説明はされていますね
- ありがとうございます！助かりました
- いまのところ、モノはエンティティ、値オブジェクト。手続きはサービスといったイメージを抱いている（もちろん、例外もあると思っている）
- 2つ以上のオブジェクトの相互作用（本書の例でいうと振替処理）を働くような、ドメインの重要な手続きをサービスとして捉えると自然なのかな
- 手続きが理解できていませんが、振る舞いはエンティティ等にも置けるので、そこに置きづらい振る舞いがサービスと解釈しています。
- P.104『サービスとは、モデルにおいて独立したインタフェースとして提供される操作で、エンティティと値オブジェクトのようには状態をカプセル化しない』
- 値オブジェクトは状態、といっていいんだろうか。
- p.106 ビジネスルール内の複数オブジェクトの相互作用、関係はドメインサービスで表現して、ビジネスルールに関係しない部分はアプリケーションサービスで表現すべきであると理解した。:+1::+1::+1:
- かなり意識してドメインサービスを設計しないとアプリケーション層やインフラストラクチャ層に記述すべき処理もドメインサービス内に書いてしまいそうだと感じた。:+1:
- P.107『ドメイン層からアプリケーション層への知識が流出するかもしれない』というのが、結構直感的にわかりづらいなぁという印象（少なくとも自分は結構理解するまで掛かった）:+1::+1:
- ユーザ重複を許してはいけないドメインルールがあるなら、それをアプリケーションサービスがDBに問い合わせしてif文でチェックする…のではなく、ドメインサービスに重複チェックを閉じ込めておく
- ドメインルールの流出、というのをもう少し噛み砕いた説明ってできないだろうか（ドメインオブジェクトの持つ値で計算、判断がアプリケーションサービスに紛れていたら、流出だ・・・とか）
- 「細粒度のドメインオブジェクトを用いると」とあるので、小さい粒度のドメインオブジェクトでは適切にカプセル化できないが、ドメイン知識に含まれるような振る舞いがある場合、アプリケーション層で直接ドメインオブジェクトを利用した場合に、その振る舞いを実装する場所がアプリケーション層になってしまう（=知識が流出する）ということかな
- アプリケーション層なしで、ドメインオブジェクトの整合性を十分に維持するようにできているか、責務が完結しているかって考えてみるとよい (系が閉じているほどよい)
- :memo: 細粒度のドメインオブジェクトを用いると〜　の文章が掛かっていると思われる。細粒度のオブジェクトを組み合わせる
- :memo: ユビキタス言語すべて≠ドメインモデル
- 用語集より:ユビキタス言語(UBIQUITOUS LANGUAGE) ドメインモデルを**取り巻いて**構築され、**チームのあらゆる活動を**ソフトウェアと結びつけるために、チームメンバ全員によって使用される言語。
- :memo: オブジェクトとオブジェクト間のインタラクションは、流出しやすい感覚ある
- 依存関係がだめと言っているのになぜみんなDBに依存関係をもたせるのか?:+1::+1:
- サービスは拡大解釈されているイメージ。基本的には副作用はダメだよって言われてますね
- p.105 *サービスと隔離されたドメイン層*
- DDDは、ドメイン層だけでなく、アプリケーション層やインフラストラクチャ層も十分に設計が行われることを前提としているのだな、というのが伺える
- 「サービス」がアプリケーション層とインフラストラクチャにも存在する、ということが示されている
- →DDDにおいては、ソフトウエアの全てあるいは大半がドメイン層に配置されるようなものではなく、ドメイン層の外にも十分な実装と設計が要求される
- あくまで、ドメインを隔離し、そこを起点にするというだけ
- 「ドメイン」と「ビジネス」が入り乱れるのが、うーんとなる:+1::+1:
- 注目したいのが「ドメイン」なんだか「ビジネス」なんだか、曖昧になっていないか？
- あるいは、明確な使い分けがあるんだろうか
- 少なくとも、定義上は「ドメイン ≠ （日本語で「仕事」などと訳されるタイプの）ビジネス」なのは明確なはず
- ここでのビジネスは、業務とか仕事ではなく、「人の関心事」的な意味でのbusiness？

## 疑問
- P106 サービスをレイヤに分割するの表にサーバーを加えるとしたら、アプリケーション層になるのでしょうか？「入力（XMLリクエストなど）を理解する」と書かれていましたが、サーバーとサービスは少し役割が違うように思ったので、同じにしてよいのか疑問に思いました。
- P104 優れたサービスの3つの特徴のうち、2つ目に書かれている「ドメインモデルの他の要素の観点からインタフェースが定義されている」の説明の意味がよくわからない。他の要素というのは他のオブジェクトということなのだろうか？:+1::+1::+1::+1::+1::+1::+1::+1:
- :memo: サービス以外のドメインオブジェクト = 他の要素、だと解釈 エンティティとか値オブジェクトとか
- :memo: サービスの引数とか戻り値にJavaBean使うとか、ActiveRecord使うとかするなよ、的なアレだと
- :memo: 「サービスの特徴」なので、他の = サービス以外、と解釈。
- :memo: シグニチャが近いイメージ
- :memo: interface キーワードと「インターフェース」という一般語は、分けた方が混乱しなさそう
- :memo: 書いてあるままと言えば書いてあるままですが、 「ドメインから生まれる概念」ではあるけど、「モデル化すると不自然」なものなので、 「クライアントに対して何が実行できるか」という観点から作られるドメインオブジェクト。 なので、その実行のインターフェス（外部提供窓口）をドメインオブジェクトに提供する。
- P.104 『ドメインから生まれる概念の中には、オブジェクトとしてモデル化すると不自然なものもある』
- 本書の例にある銀行の振替処理以外に、不自然なものとは、どういうものだろう。:+1::+1:
- :memo: 振替が片方の口座の振る舞いと考えるには不適切だと思います
- :memo: 「銀行員」という概念を用意すれば、銀行員の振る舞いとして定義できる気がする （でもすべての振る舞いを実現できてしまう）
- :memo: 神クラス「銀行員」
- :memo: オブジェクトとオブジェクトとの間のインタラクションとしてある概念を、いずれかのオブジェクトに損草セルのは不自然なので、インタラクションに相当する概念として定義するのが妥当で、それをオブジェクトとしてもよいし、オブジェクトたり得ない何かであるならここでいうサービスとする感じ。
- p.106 「ドメインオブジェクトと外部リソースの間に直接インターフェースを設けるとぎこちなくなる。... ファサード(FACADE)を被せればよい」というのはファサードをドメイン層にサービスとして設計して、外部リソースの処理自体はインフラストラクチャ層に書くという意味であってるのだろうか？
- ドメインサービスはドメイン層の知識をアプリケーション層に流出させないために、ドメインオブジェクトの振る舞いを組み合わせて、ドメイン知識としての振る舞いを定義する場所、と考えると、集約との違いは一体何なんだろう？
- Evans的には、オブジェクト = 物？:+1:
- （物ではない）コトは、Evans的にはオブジェクトとしては（少なくとも、積極的には）認めたくないのかしら
- *時には、単純に「物」とはできないこともある* p.103
- :memo: 物 --> thing = 「何か」
- *サービスは、実態よりも活動、つまり名詞よりも同士にちなんで命名される傾向がある* p.104
- 全体的に、サービスという概念の導入に対して苦々しさを持って書いているように感じる
- :memo: オブジェクトはデータ+振る舞いですね。 サービスは振る舞いだけで、副作用は持たないってイメージ
- :memo: object は「対象」と訳し、モノだけでなくコトも含まれる派（なので、アレ？となった）
- :memo: 逆なのかなあ、 object = （なにがしか輪郭を伴うような）モノだと思っている人に対して、 「いや、objectの範囲はそこに限定されないよ」とEvansは説明しようとしたのかなあ （それにしては、サービスの項全体で、なんとも苦しげな印象を受けるのはなぜだろう）
- :memo: どこで聞いたか忘れましたが、公園にある大きな石は椅子にもなるし、遊具にもなる。 オブジェクトは意味と責務をもたせたものって聞いたことがあるような
- :memo: 逆にドメインをモノと捉えない方がわかりすいと思っていて、 ドメインの「活動」に対してEntityやValueObjectといったモデルに当てはめるのは不自然な「活動」があるよ。それは「サービス」にしようね。 って話だと思います。
- :memo: オブジェクトとオブジェクトとの間のインタラクションとしてある概念を、いずれかのオブジェクトに持たせるのは不自然。インタラクションに相当する概念として定義するのが妥当で、それをオブジェクトとしてもよいし、オブジェクトたり得ない何かであるならここでいうサービスとする感じ。
- :memo: でもまあ、振替業務とかにこだわらなければ、よくある例で、 サークルとメンバーがいて、参加ってどっちに持たせる？って話では。
- :memo: なんでもかんでも「サービス」として引き剥がすとヤバい、という本文の警告も、 「それインタラクションなの？」というツッコミで防げそう
- ドメインサービスのクラス名はOOServiceと名付けますか？:+1::+1::+1::+1:
- 過去の苦い経験からServiceとつけることに抵抗感があったり...
- :memo: XXDomainService (Service単体にはしない)
- :memo: 書籍から学ぶ人には、DomainServiceとあるとわかりやすそう
- :memo: 最近サービス作って、Serviceつけようとして {動詞}{目的語} なクラス名にした（ Service という語を使いたくない症候群）
- 動詞をクラス名にしないで {動詞 ing}{目的語} だとどうなんでしょうか？ :thinking_face: (クラス名に動詞ってそのまま使う場合ってあるのかなぁ？という疑問です(DDD初心者))
- p.107 *サービスへのアクセスを提供する手段は〜* :+1:
- ここでの「サービスへのアクセスを提供する手段」のあたり、どういう問題意識からこの話をしているのか、ちょっとピンとこない
- J2EEとかCORBAについて知識があれば、「あー、アレとかソレとかね」となるのかしら
---

# モジュール（MODULES)（別名　パッケージ（PACKAGES））
## 目安の時間
- 30分

## 感想・気づき
- モジュールが結局DDDにおいてどういう存在なのかいまいちわからない。。。:+1:
- :memo: まずはドメイン層を他の層から分離する為に、domainというパッケージを切ることなのかと思っていました。その中では集約ごとにパッケージを切っていくイメージ。
- ドメインモデル図のような役割を果たすと思っています。パッケージ自体が概念の枠になるので、「この概念には、この要素が内包されている」とか「この概念と、この概念は別」ということの認識がメンバー全員で統一されます(違和感を抱くものが居れば討論の機会にもなり、知識が噛み砕かれていく)。エヴァンスが「モジュールもコミュニケーションの仕組み」と言っているのは、ここら辺と繋がっているのだと解釈しました。
- なるほど　なんとなく掴めてきたような気がします　ありがとうございます！
- P.109 『分割される意味が、モジュールの選択を駆動させなければならない。』
- 先にモジュール分けをしたら、その中身がどうなっても名前を頑なに変えない・・・ というダメパターンって凄く良くあると思う。:+1:
本来はモジュールがオブジェクトを駆動するし、オブジェクトがモジュールを駆動すると思うのだけど、自分は上手い言葉で表現できていなかった。
P.110 の『アジャイルモジュール』という言葉はその内容を的確に表すヒントになるのでは、と感じた。
- P.113「制約があるせいで、もしくはパッケージが大量に必要であるというだけでも、ドメインモデルの必要性に合わせた別のパッケージ構成を使うことが認められなくなってしまうのだ」
- プロジェクトごとに作る制約も、大体技術フレームワークに則った制約が多い気がしている:+1:
- P.114「ドメインモデルに由来する概念は、それぞれ、実装上の一要素に反映されなければならない」
- これが一番言いたいことなんだろうと思っている
- 「階層が深くなるのが苦手」という層は結構いて、概念単位で切るのが難しい時がある(これも結局モジュールに限らず、DDDへの理解をどう認知させていくかという話に落ち着きそうだが)
- 実践UMLオススメ
- そう言えば低結合なんですね。疎結合じゃなくて。:+1::+1:
- （ドメイン）モデルに基づいた設計・構造化（＝モデル駆動設計）は、プログラムだけでなく、その集合としてのモジュール（パッケージ）に対しても適用される、というお話し
- CA本が、SRPをプログラムだけでなくレイヤにも、（単体アプリケーション的な意味での）サービスにも適用できる、という議論を展開していたのを連想するなど
- あくまで連想

## 疑問
- P.109「概念上の関係性について考えることは、技術的な評価の代わりではない。」
- 「技術的な評価」とは何のことか？:+1:
- P.109「トレードオフが避けられない場合は、概念的な明確さの方を選んだほうがよい。」:+1::+1::+1::+1::+1:
- 「概念的な明確さ」と何のトレードオフ？
- :memo:
- :memo: その上の、モジュールの選択とのトレードオフでしょう。 疎結合になることを推奨しているけれど、疎結合にすることで概念の明確さが失われるならば、概念の明確さを取りましょう。と。
- :memo: その後で「それによってモジュール間の参照が増えたり〜」とあるので 技術駆動のパッケージングによって、参照を減らせるとか、diffが押さえられるとか そういうメリットよりは、概念上の明晰さを選びましょう、的なアレだと理解
- :memo: 低結合になりやすい ならない場合は以下を検討しましょう 成立せずにトレードオフが避けられない場合は 「概念的な明確さの方を選んだ方が良い」
1. 概念のもつれをほぐすような...
2. 意味のある方法で要素をまとめ...
3. 相互に独立して理解でき...
4. モデルがドメインの高次まで...
- P.113「1つ例外が発生するのは、コードが宣言的設計に基づいて生成されるときである。その場合、開発者はコードを読む必要がないので、邪魔にならないように別個のパッケージに入れて、開発者が実際に取り組まなければならない設計要素を混乱させないようにした方がよい。」
- 宣言的設計しているコードは、ドメイン層やその他のコードとも分けて、別個のパッケージに入れた方がいいよ、と言っている？
- エンティティ、値オブジェクト、ドメインサービスではなく、モジュールとしてモデルを表現した例ってなにがあるだろう？:+1:
- module/package/component など「全体に対する部分としての要素」を表現する言葉って色々あるけど、この言葉の違いによる粒度の大小というのは、英語話者には常識的に区別がつくようなものなんだろうか？:+1::+1:
- モジュールの概念は難しいのですが、どうやって切っていますか?:+1::+1::+1::+1::+1::+1::+1::+1:
- :memo: モジュールってなんだろう。（ここまできて
- :memo: 何某かの基準でまとめられたまとまり = モジュール、みたいなふんわり感覚 その基準として、（技術的な都合とかよりも）ドメインの知識・概念を使いましょ、というのがEvansの主張という理解
- :memo: (IDDD本) DDDにおいてモジュールとは、ただの入れ物ではなく、 **別のモジュールのクラス群との結合を少なくする** という目的を持つ。そのため、モジュールに適切な名前をつけることは重要である。そのため、高凝縮で低結合なモジュール化されたモデルを、ユビキタス言語に従って構築することがポイントになる。
- 「システムに関する物語を伝え、概念の凝集した集合」のあたりが抜け落ちた感じの説明で、ちょっと違和感 > IDDD
- :memo: DDDの"コンテキスト"と、この"モジュール"の関係がわからない(どちらの方が粒度が荒いのか)
- :memo: コンテキスト=海 モジュール=船
- :memo: コンテキストはcontextであり文脈なので、 モジュールのありようを決めるもの、みたいな感覚
- :memo: 粒度というか、そもそも役割が違う的な
- :memo: まあ、まじめに言えば、ドメイン層でいえば集約がモジュールとなると思う
- :memo: モジュールを構成するモジュールという形にもなると思うので、 「○○がモジュールの基準、それ以外はモジュールにしない！」ということはなく 「システムに関する物語を伝え、概念の凝集した集合」になるものはモジュールとしてくくるのが良いのじゃないかしら、感
- :memo: この章の趣旨としては、アーキテクチャが決めた各領域内のモジュール分割の話をするべきでしょうね。
- :memo: 冒頭でドメイン層のモジュール

---

# モデリングパラダイム
## 目安の時間
- 30分

## 感想・気づき
- 開発者、非開発者がわかりやすいこと、ツールのサポートがあること、コミュニティやエコシステムが成熟していることが、オブジェクト指向設計が広まった理由の一つなんだと思った:+1:
- これらの条件が満たせれば、他のモデリングパラダイムが流行るのかもしれない
- パラダイムの混在….NET系だったら、F#とC#を連携させるようなイメージかな？
- パラダイムの混在をさせることは可能だけど、その選択肢を選ぶのはかなり最後の方であり、できる限りいま使っているパラダイムで表現できないか模索することが重要なんだという気づき
- あまりパラダイムが混在した例というものを見たことがない
- UMLにこだわりすぎない、というのはそのとおりだと思う。とにかく重要なドメインの概念やルールが明示して伝えることができることをちゃんと目的として忘れないようにしたい:+1::+1:
- この中でオブジェクト指向を理解している人はいますか?
- パラダイムの選び方、大体「言語どうやって選ぶ？」というお話しと似通ってる印象
- 「なんでJuliaじゃなくてJavaを選ぶの？」に対する回答も、大体同じような論理展開になる印象
- p.119 *本節が目標としているのは、モデル駆動設計を断念する必要はないことと、それを保つ苦労はする価値があるということを示すことだけである*
- どのパラダイムを選ぶにせよ、パラダイムを混在させるにせよ、「モデル駆動設計」という土台は変わらないし揺るがない（はず）だよ、というお話

## 疑問
- P.114 パラダイムの定義とは何だろう？
○○型言語、○○志向、○○フレームワーク、MVC的な○○○ 的なものはすべてパラダイムと言える？
- :memo: ドメインにおける諸概念を切り取る特定のスタイル
- :memo: "思考のスタイル、研究対象に立ち向かう態度" ことDDDにおいては、この「対象」がすなわちドメインだと
- :memo: 〜〜型言語、というのは、「プログラミング」パラダイムですね。
- :memo: 構造化設計、オブジェクト指向設計、データ中心設計、ドメイン駆動設計 それぞれパラダイムであり、パラダイムの具体例であり ドメイン駆動設計 implements パラダイム 構造化設計 implements パラダイム データ中心設計 implements パラダイム みたいな関係だと思います
- :memo: どういうスタイルで問題に立ち向かうのか、に近いのでしょうか
- P.114 2020年現在のパラダイムと言えばどんなものがあるんだろう？ :+1::+1::+1::+1::+1:
- P.119「パラダイムに合うモデルの概念を見つけること。」
- 「パラダイムに合うモデルの概念」とは？
- プログラミングパラダイムとモデリングパラダイムは（オブジェクト指向言語と、オブジェクト指向モデリング）は分けて考えるべき？ :+1:
- :memo: プログラミングパラダイムの1つとしてオブジェクト指向がある感じじゃないかな。
- p.111 「モデルオブジェクト」って何？
- 唐突にでてきたけど、「ドメインオブジェクト」との違いは何？
- 同じ意味なら、「ドメインオブジェクト」って書くよね

---