DDD本 序章、目次、索引
===
###### tags: `エヴァンス本読書会`

# Discord開始位置

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

# 自己紹介

- なかじま（J.Nakajima）
- ファシリ役
- タイムキーパー役
- こばやし（t2_Kobayashi）
- 読み上げ役
- miro役（裏の書紀役）
- Philomagi（ふぃろまぎ）

# 参加の仕方

- マイクはいつでもONにして、話に参加して結構です。
- テキストチャットでも、コメントとかするなりしてもらって大丈夫です
- 聞いているだけの方もOKです

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

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

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

---

# 最初に、みんなの質問を眺めて :+1: をつけるタイム
## 目安の時間
- 10分

# 1.本書に寄せられた賛辞
## 目安の時間
- 10分

## 感想

- a. 一番最初の「本書に寄せられた賛辞」の中で、リファクタリングEric Evansの大事なテクニックの一つになっている、と語られているのは、世間一般的に言われているDDDの中では、あまり語られていないというか、あまりフォーカスあたっていない気がする（あまりにも当然だからなのかもしれない） :+1::+1: :+1:

## 気づき

- a. 「本書に寄せられた賛辞」にて、「ソフトウェアの設計を、今取り組んでいる問題ドメインのメンタルモデルに適合させる」という言葉。 :+1::+1::+1::+1::+1::+1:
- 「一致」ではなく「適合」。
- ソフトウェアと「適合」させるのは、ドメインそれ自体ではなく「問題ドメインのメンタルモデル」。
- この一文は、ドメイン駆動設計におけるドメイン-ドメインモデルの関係を理解する上で、示唆深いように感じる。
- メンタルモデルとは、その従業員の頭の中にある内面モデル
- メンタルモデルをドメインモデルとして表現し、ユビキタス言語として共通言語を組み上げていく、ことではないか
- b. 「オブジェクト指向プログラミング との差異」や「投資効果」に軽く触れてた事 :+1::+1:

## 疑問

---

# 2.日本語版への序文
## 目安の時間
- 10分

## 感想

- a. P.vi末尾(日本語版への序文). ずいぶんポエミーな本だなぁと思っていたが、Evans 自ら『これは一人の人間の物語です。』と寄せていた。技術書だけど物語だと思うと非常に納得感が出た。 :+1: :+1:
- b. 序文で3つの原則がでているけど、この3つはDDDで実践していないことなんだよなと思いました。やっぱり銀の弾丸はないし、「知性と忍耐が必要」とはじめに言うのは好き。 :+1::+1::+1::+1:
- 同様に勇気も必要。
- c. P.iii 3つの原則のうち「ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探究すること。」について。POC的な特にドメイン実践者側のトライ&エラーやスピードが求められる際や、誰も正解を知らない物を作り上げる際、共同作業に時間を割くことへのしにくさや、手探り感が出てしまうなという感想。 :+1: :+1: :+1::+1: :+1:

## 気づき

- a. Evans 自らが、出版から7年経過した段階で『根本的には、DDDを駆動している原則は次の3つだけです。』と断言しているからには、この3つが超絶大切なことである筈。 :+1: :+1:
- **コアドメイン** に集中すること
- ドメインの実践者とソフトウェアの実践者による創造的な共同作業を通じて、モデルを探求すること。
- 明示的な **境界付けられたコンテキスト** の内部で、**ユビキタス言語** を語ること。

## 疑問

---

# 3.日本語版推薦文
## 目安の時間
- 10分

## 感想

- a. 日本語版への序文で原著が出たのは2003年だったことと、それでもDDDの方法論が色あせてないことに、あらためて驚き :+1:
- b. 日本語版推薦文:DDD難民(原著が出てから翻訳版が出るまでの期間に人口が少なく議論出来なかった時代があること)を、最近知りました :+1:
- c. 日本語版推薦文:「本書を貫くもう一つのテーマはリファクタリングだ」ということ、忘れがちがだが「既存のものを変えていく」ところに力点を置いていることを再認識 :+1::+1:
- d. 3つ目の日本語版推薦文(平鍋健児さん)、「ソフトウェアのデザインは、チームのデザインでもある」とありますが、DDDとチームビルディングが直接関連していると思っていなかったので、本文中でどのように書かれいているのか読むのが楽しみだと思いました。 :+1::+1: :+1:
- e 日本語版推薦文:(1つ目 榊原　彰)「が、返答は『既に翻訳権が取得されている』というもの。何度も言うが、今まで出版されなかったことは私にとってはバミューダトライアングルよりもネス湖の恐竜ネッシーよりも深い深い謎だった。」翻訳権をロックしてたのだれですかー！？:+1:
## 気づき

- a. やっぱり重要な概念が理解され、浸透するまでには10年くらい時間がかかるのだなと再認識した :+1:

## 疑問

- a. P.vii 「DDDにおいてはドメインを記述する単位をオブジェクトからより自然な「ユビキタス言語」というDSLの次元に持ち上げることで、より的確に表現されている。 」のDSLの意味がよくわからなかったです。 :+1:
- [ドメイン固有言語:DSL](https://ja.wikipedia.org/wiki/%E3%83%89%E3%83%A1%E3%82%A4%E3%83%B3%E5%9B%BA%E6%9C%89%E8%A8%80%E8%AA%9E)
- DSL は`一種類のタスクをうまく実行することに集中したもの`
- ユビキタス言語は対象ドメインに固有の言語ってことだと思います
- b. P.viii 羽生田さんの日本語版推薦文の「パターン・ランゲージの形式をとっていることの意味は大きい。」の意味がよくわからなかったです。 :+1: :+1: :+1:
- クリストファー・アレグザンダーのパタンランゲージが採用した形式(問題サマリと解決サマリ)があってそれに沿っているということですね。
- c. P.xiii 「対照的な３つのプロジェクト」の最後の1つのプロジェクトが、深い分析を伴ったモデリングができていたのにも関わらず失敗し、その原因が開発者間のスキルレベルが不均一だったというのが疑問です。分析/モデリングするチームと設計/実装するチームが分かれていていたからモデリングで得た深い洞察が実装に反映されなかったのが原因のような気がしてしまいます。 :+1: :+1:
- d. 2つ目の日本語版推薦文(羽生田栄一さん)、クラウドコンピューティングとDDDにはどんな関連があるのかなと思いました。 :+1: :+1:
- e. 原著が2003年、なので出版から17年、翻訳版からで8年近く経過していることになるが、この当時から「現在のDDD」まで、進化や差分はあるのだろうか？ :+1:
- これは今後読んでってわかることだとは思うが
- f. 「それがクラウドコンピューティングという大きな環境の激変の中で、現場に入って行って現場の声と一体化したシステム作りのできないソフトウェア屋さんは存在価値がないという時代の訪れとともに、DDDの重要性の再認識どころかその実践の必要性に迫られている。」 :+1: :+1: :+1::+1:
- ビジネス戦略がなくとも、ドメインは存在するのだろうか？業界ドメインという意味では、ありそうだが、事業がどう進んでいきたいのかという方向性がない場合、ドメインが存在しないのでは？と思った。現場にある問題を解決することが、正しいのだろうか？

---
# 4.序文
## 目安の時間
- 10分

## 感想

- a. 「モデルは実装だし、実装がモデルだ」「図でも概念上のものでもないし、一回書ききりじゃないし、育てるもんだ」という「感じ」がした :+1:
- b. 序文がマーチン・ファウラーかー! Martin Fowler's BlikiにもDDD関連のはなしはちょくちょく出るからな :+1::+1:
- XPの話も出ているし、パターンの話も出ているから妥当なのかな…
- c. 大企業ですと、マネージメントから社員が実装することを嫌がられるのですが、そうなってくると社員やマネジメントが概念を正しく理解できないのが課題だな、と思いました。:+1:

## 気づき

- a. 序文から「ドメインモデルというものが、最初にモデル化され、その後の実装されるようなものではない」という中から、「モデルと実装は行き来する」ということを言い表していて、だからこそリファクタリングが重要なんだ、という言葉が、他の人達からの推薦文にも言及されているんだろうと思える :+1:
- b.「概念モデルの否定」のところで __役に立つ__ が強調表示されていたこと :+1:
- よほど「役に立たねーよ」という思いを多くしてきたのだろうｗ:+1:

## 疑問

---
# 5. まえがき
## 目安の時間
- 10分

## 感想

- a. まえがきにある3つのプロジェクトの対比がとてもおもしろい。2つ目のプロジェクトは、まさにドメインモデルから実装へのフィードバックを得てさらにドメインモデルを繰り返し改良していく、ということを示唆している :+1::+1: :+1:
- ①モデルを作ることなく、設計者たちの勘で進めた為に、第2リリースが難しくなった
- ②ドメインモデルを作り、そこから前のリリースの機能を統合して練り上げるための、刺激的で新しい選択肢が開かれていった
- ③ドメインモデルは作っていたが、実装者とモデラを分断してしまった
- b. p.xvの「設計対開発プロセス」の中で、「設計のテクニックを学ぶときには、それがもたらす可能性に興奮するものだ。それから、実際のプロジェクトのひどい現実が降り掛かってくる」は、勉強会に行って、「さあ頑張ろう！」という中で、ひどい現場に直面して挫ける様子に似ている :+1: :+1:
- c. P.xvの設計対開発プロセスの中で、「設計とプロセスは切り離せない」とエヴァンスが言っているのは、なんとなく「設計と実装は切り離せない」というメッセージにも近いのかなぁと思った :+1:
- d. p.xviの分析麻痺という言葉は、開発者が陥りがちなパターンを、ちゃんと言語化していて、名前を付けていることに、とても有意義だと思っている :+1:
- e. 「多くのアプリケーションにおいて、最も重要な複雑さは、技術的なものではない」 :+1:
- システムを構築する時点で、ある程度の複雑を切り捨てることも大切なのかも
- f. DDDを行うための前提条件: 「開発者とドメインエキスパートが密接に関わっている」 :+1: :+1:
- 困難な前提だが、逃げてはいけないと思った
- g. 「ドメイン駆動チーム」から。DDDやるには「組織設計もご一緒に」だなぁと思った
- だからといって「ハードル高いね」とはなりたくなくて「何をやるにも新しい取組には組織・チームの変化は普通だね、にしたい

## 気づき

- a. まえがきの「モデルは深みを増していった」で言われている「深み」とは、ドメインの本質をより捉えている、という感じなのかなと思った :+1:
- b. まえがきで「8章が気に入ってるよ」とエヴァンスが言ってたこと :+1::+1::+1::+1::+1:
- c. XPをちゃんと読んでないのでアレですが、P.xvにあるDDDアプローチの前提条件にある「開発がイテレーティブであること」というのは、モデル⇔実装をフィードバックしあって行き来することを前提と考えているからなんだろうと思った。その意識が抜けなければ、とりあえずはいいのかなぁと。 :+1:
- d. P.xvi 『分析麻痺』という言葉はイメージも伝わりやすいし、もっと一般的になってもよい単語だと思う。 :+1:
- e. P.xix Evans は第1部1章から読むことをお勧めしている。 :+1:
- 同、中核となる章は2, 3, 9, 14章とのこと。
- 黎明期のDDDコミュニティでのおすすめの読み方は、第1部 → 第3部 → 第4部 → 第2部でした
- f. P.xix DDDではドメインエキスパートとチームの関係性や共通言語がよくフォーカスされるが、それと同じくらい、チームの中で共通言語を作り上げて活用する文化を作り上げていくことが大切である。 :+1: :+1:
- ※ ドメイン駆動チームの節で『最大の収穫を得られるのは、チームが一致団結してドメイン駆動設計アプローチを適用し、ドメインモデルをプロジェクトで交わされる会話の中心に持ってきた時である』と記載がある。
- g. P.xviiの本書の構成、第三部からの話ってもしかしたらリファクタリングの話に踏み入っているのかもしれない :+1:
- 第一部、第二部でとりあえず最初に捉えたモデルを実装に表すところまでをやってみて、そこからリファクタリングを通じてより深いモデルを作っていくことが大事なんだ、ということを第三部、第四部で伝えようとしているのか？
- h. P.xiv 「手に負えないほど複雑になると、開発者はもはやソフトウェアを十分には理解できなくなり、変更や拡張を容易かつ安全に行えなくなる。」が分かりすぎて過去を思い出した。:+1::+1:

## 疑問

- a. P.xivの複雑さという課題の中で、「優れた設計であれば、そうした複雑な特徴を活用する機会を作り出せる」とあるのは、モデルを極力シンプルにするとかではなく、あくまで利用をするっていうことなのだろうか :+1:
- b. P.xviの「役に立たない固定化したドキュメント」とありますが、役に立つドキュメントと役に立たないドキュメントの違いってなんでしょうね？ :+1::+1::+1::+1::+1:
- c. 1つ目のプロジェクトの例は「小さく、期待のない実験的プロジェクト(場合によってはMVP、ベータ版やプロトタイプ)でも、DDDで作っといたほうがいいよ」って話かなぁ？ :+1:
- 「アプリケーションのライフサイクルを(ある程度)読めてるか」がDDDでソフト作るかの鍵になってきそう
- ま、自身チームがそれで成功して「必殺パターン」になってたら、自ずとそれで作るだろうけれど
- 未経験で「導入のコスト」を払ってでも、小さなプロジェクトに適用したほうがいい…って言う原理主義じゃない、とは思うけれども
- d. 「設計対開発プロセス」の話。ま「アジャイルと相性は良い」はわかってたけど、「WFっぽいV字モデル開発 と DDD」は両立できないものなのか？ :+1::+1:
- 不毛かつ荒れやすい話題ではあるものの、敢えてちょっと考えてみたくなったｗ
- モデルを分析と設計で分割しないで、単一のモデルを目指すので、WFは難しいのではないかな
- e. 2段落目の最後、「成功したプロジェクトに共通する特徴は、豊かなドメインモデルがあったということだ」の「豊かさ」とは？:+1: :+1:
- ドメインの特徴を的確に捉えているもの

---
# 6.謝辞

## 感想
## 気づき
- 「JoshKerievskyは、本書の執筆における、大きな転機の1つをもたらした。彼からは「Alexander流」のパターンフォーマットを試すことを勧められたのだが、これは本書の構成の中心となった」:+1:
- こんなところにもアレグザンダー
- 参考資料にも、先頭で出てますね

## 疑問

---
# 7.翻訳者謝辞

## 感想
## 気づき
## 疑問

---
# 8.目次
## 目安の時間
- 10分

## 感想

- a. P.xxvi~xxxiii 目次を見ると日本語に訳されていても、どんな概念や意味なのかが思いつきづらい言葉があるので一つ一つ定義などを確認する必要があるなと感じました。（集約、順応者、蒸留など） :+1:

## 気づき

## 疑問
- a. なんでこの章立ての構成なんだろう？　なぜ、知識を噛み砕くという抽象的な話から、具体的な戦術的設計、最後に戦略的設計の話をするのか？ :+1::+1:
- 境界づけられたコンテキストの話が、最初にされておらず、第4部あたりで出るのも気になっている

---

# 9.索引
## 目安の時間
- 10分

## 感想

-
## 気づき
- a. 推薦文やはじめにのエヴァンスが言っているように、リファクタリングの項目が、索引の中でめっちゃ数が多い（17個もある） :+1:

## 疑問

---

# 10.全体（章によらない、全体的な)

## 感想

- a. 仕様:アナリシスパターンを参考にするなんて泥沼 :+1:

## 感想

- この２年間はじめてドメイン駆動設計で既存のシステムの再実装してみましたが、コンテキストに区切って、ユビキタス言語でしゃべりモデリングしようとしましたが、うまくいかず中途半端なものができました。序章？にも書かれていましたが、インフラ層を外において、ドメインモデリングすればいいとわかっていても、実際の実装に落とせなくて結構つらかったです。エバンスが言っている「これらの原則を明確に理解したとしても、成し遂げるのは容易ではありません」痛感しました。

## 気づき
## 疑問

- a. この読書会の参加者比率で、DDDへの取組が「今から」と「既に」の割合 :+1::+1:
- Discordとかでリアクションアンケート取りたい感じ
- DDDこれから学ぶ！
- DDDやってる！