DDD本 3章：モデルと実装を結びつける
===
###### tags: `エヴァンス本読書会`

# Discord開始位置

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

# 自己紹介

- なかじま（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です。

---

# 第3章 序章
## 目安の時間
- 18分

## 感想・気づき

- 冒頭の壁一面のクラス図の例から、クラス図で表現していても実装に落とし込めないことがあるのだなぁと思った。
- P.43の「アプリケーションのコードと設計に対する洞察が全く得られないとわかったことだ」が、モデルと実装の乖離を表している？
- P.43の「その場しのぎの設計に取り掛かった」というのは、開発者たちがわかるような言葉で構成された設計(xxID、xxコード、xxフラグなど)にのことを言っているような気がしている。
- P.44の「コードに対するアプローチほどはっきりしてないが、モデリングに対しても、ドメイン駆動設計では別のアプローチが求められるのだ」:+1:
- 次の節で出てくるモデル駆動設計の話？

## 疑問

- P.43「モデルは実装のための指針を提供しなかったのである」
- 実装のための指針を提供するモデルとは、いったいどんな物になるか:+1::+1::+1::+1::+1::+1::+1::+1::+1::+1:
- :memo: 論理モデル、RDRA
- :memo: 注目すべき要素が見えるモデル（というかソフトウェアに無関係な情報がないモデル）って思って読んでました
- :memo: 文脈的に単純に考えれば「実装でけへん図」とか、そんなハナシだったのかな？
- :memo: チームメンバーと実装イメージを共有可能なもの。
- :memo: トラックモデルがあって、荷物を運べるとか燃費とか排気量がとか書いてあるモデルって、どうすりゃいいねんってなるじゃないですか
- :memo: 「コンサルタントみたいな人が机上の空論 的なモデル」へのアンチテーゼ的な文脈だと推測
- :memo: DDDでない場合のクラス図は、クラス名に概念名が出ていても、設計が読み取れないみたいな話がありました。それの反対かなと。設計が紐づいているもの？
- :memo:「なるほど完璧な作戦っスねーっ不可能だという点に目をつぶればよぉ〜」
- :memo: トランザクションとかそこらへんを一切考慮してない場合も多いよね
- :memo: コンテキスト跨ぎとか、依存関係がはっちゃけているとかもありそう
- データストレージでは、モデルにあるのと同じクラス名や属性がいくつか使われていたが、既存のモデルに基づいていなかった
- これはどうやって判断できたのだろうか:+1::+1::+1:
- :memo: モデルと実装が違うやつですね。理想の論理モデルとか
- :memo: オブジェクトデータストレージっていう前提もあるし、そのままでいいはずなのになんで？　ってことじゃないかなぁ
- :memo: 例えば、(今回の例は違うけど)RDBMSとかなら「オブジェクトのフィールド名とクラスが、テーブルとカラムと全然違う（なんなら、入れ子になってたり、全然遠いテーブルについてたり）」とかなら「こいつ…中途半端に後付しよったな」とかなります、けどねぇ。
- P.44「不気味なことに、これらの2つのプロセスの最終成果物は非常によく似ていた！」に出てくる、2つのプロセスってどれのことだろう？
- アナリストとビジネスサイドが壁一面にクラス図を一生懸命作り、実装者は別になったこと。
- C++→Javaアプリに置き換えたプロセス？
- モデル=ドメインモデル？:+1:

---

# モデル駆動設計
## 目安の時間
- 18分

## 感想・気づき

- 自分が、「モデリング」と「設計」を同一視していたのに気づいた。この節を読んで、なんとなく別物なんだなというのは理解できたが、具体的な違いはうまく言語化できない…。:+1::+1::+1::+1::+1::+1::+1:
- なぜ実装ができない人が設計をするんだろうか?そして、なぜ設計する人が偉そうなんだろうか?:+1:
- 「モデルを1つだけ開発して、それによって問題を捉えつつ、実用的な設計を提供する」モデリング開発のことを指していると思うが、混乱しか見たことがない
- 最終的な実装コードをイメージできない人がどうしてモデリングだとうまくいくと思うんだろうか? :+1:
- P.46「開発者が設計のために新しい抽象を考え出さざるを得なくなると、そのほとんどが失われる」というのは、 P.43の「その場しのぎの設計に取り掛かった」の話に通じている気がする。
- 設計のための新しい抽象・概念が出てきてしまって、そこで初期の分析モデルとの乖離が起きて結びつかなくなってきてしまう。
- P.46「重大な発見はいつでも、設計や実装をするために努力する際に表れるからだ」は、完全同意。:+1::+1::+1::+1:
- コードを書くなど実際に手を動かさないとフィードバックは得られないのを痛感する。
- 『おれのかんがえたさいきょうのせっけい』が実装段階で何度も爆死しているのでお腹痛くなりそう。:+1::+1::+1:
- P.47「モデル駆動設計は、分析モデルと設計という二分法を捨て去り、両方の目的に使える単一のモデルを探し出す」:+1:
- P.48「コードから要求の分析に至るまで一貫して、適用されるモデルは1つだけであるべきだ」:+1:
- コードからモデル、という言い方じゃないのがミソっぽい。いま書いているコード（で実現できる機能）と要求がちゃんと紐づくというトレーサビリティの話を示唆しているように思える。:+1:
- p.46「純粋な分析モデルはコーディングが始まるとまもなく捨て去られ」
- 以前モデリングの習慣がないチームで、モデリングに基づいての実装を試してみた。いざ実装してみると、他のチームメンバーによりモデルは即座に無視され、モデルに基づかない技術駆動な実装に堕してしまった。様子を伺っていると、どうも既存実装にどんどん引きずられているようだった。:+1::+1::+1::+1::+1::+1::+1::-1::+1::+1:
- p.46「行為を説明することができない機械仕掛け」
- 「技術駆動な実装だ」と述べていると思う
- p.46「ソフトウェアが正確であるかどうかも疑わしい」
- 「正確にドメイン目的を達成するものか疑わしい」と述べていると思う:+1:
- P.46「設計が、あるいは、設計の中心となる部分が、ドメインモデルに紐づいていないならば、そのモデルに殆ど価値はなく、ソフトウェアが正確であるかどうかも疑わしい」という文章を見てDDDに期待を持った人間です。複雑なドメインの中でお金になるドメインを見つけ（コアドメイン）、コアドメインに関して、ドメインエキスパートと一緒に分析モデルと設計モデルが整合しているモデル（分析モデルの知識が流出していない設計モデル）を作成し、そしてソースコードとモデルが整合している状態。この状態であれば、ソフトウェアの拡張・保守が容易になると考えています。（今までモデル・ドキュメント・ソースコードが乖離したソフトウェアの保守・拡張に苦労してきたので・・・）:+1::+1::+1:
- P.46「設計が、あるいは
- テスタブルなドメインモデル＆整合がとれたソースコードがある状態だと、ドメイン自体がソフトウェアによって検証可能であるともいえる？＝モデルの価値？
- 20年前「オブジェクト指向」を知って、10年前くらい現場入って「分析モデル」と「物理モデル(実装クラス図、とも言うてた)」が違うこと、また初期の図を「書捨ての一資料」にしていたことについては、ずっと違和感だった。UMLクラス図の表現上「詳細過ぎるからフィールド・メソッドは省略」とか「膨大すぎるから一部を切り取る」とかするのはいいとしても「実装がモデルでしょ？(つまり一つででええやろ)」と思い続けてた。20年目くらいの現在「DDDに出会った」ことで「やっぱそやんなぁ」という初期の衝動が遂げられてた気持ちだ。

## 疑問

- 「ドメインモデルを持ってない、次から次へと機能を満たすコードを作成するだけのプロジェクトは、これまで2章で述べた、知識のかみ砕きとコミュニケーションによる恩恵をほとんど受けない」
- ドメインモデルを持ったとして、それはどこで表現することが嬉しいのだろうか？README？それともプロジェクトの専用Wiki？（ドメインエキスパートもよく見る場所？）:+1::+1::+1:
- :memo: ドメインモデルの保存場所はどこか
- 写真
- ホワイトボード
- 口頭伝承
- wikiだと誰も見てくれない
- スマホの壁紙
- 開発する時に、api設計とかdb設計とかする前にドメインモデル図を関わる人で一緒に更新する、というフローが作れれば、わりと定着させられる手応えがあります
- 人は必要もないのに見るとかしないので見る必要性をつくらないといけないとなると、開発プロセスに組み込むのがいいんです
- QiitaTeamとかmiroとかで書かれているのをよく見かけるけど、作成日時をめちゃめちゃ気にする。なぜなら図が陳腐化して現在とモデルに対する考えが変わっている可能性があるから。
- モデル図作って、英訳当てて、それを元にエンドポイント名とかdbとかエンティティの名前に反映するんです。となると、ドメインモデル図を更新する必要や見る必要性が生じる
- そのモデル図自体がユビキタス言語のマスタになればいいんです。別途用語集みたいにするのは運用されなくなるよなーというイメージ
- 「ドメインモデル図で先にイメージ合わせておかないとずれちゃうじゃん、api設計とかより先にやった方がいいでしょ」って流れを作れたら理想だと思います
- 表現時は「このプロジェクトのドメインモデルは～」とかで始まるのだろうか？
- 「ドメインを抽象化する方法は常に数多く存在し、アプリケーションの問題を解決できる設計も常に数多く存在する。だから、モデルと設計を結びつけることは現実的に可能なのだ。」これは言い切れるのかと思ったが、モデルと設計を結びつけることができない＝実装できない、となるので逆説的に結びつけることはできる、ということなんだろうか？:+1::+1:
- :memo: 二分法に対する説明だと思う
- :memo: p.46「設計の方法論の多くは分析モデルを作ることを主張する。こ れは設計とはっきり区別され、通常は別の人々によって開発される …… 分析モデルはビジネスドメインを 理解するためだけに使うツールとされ、実装の問題を混ぜてしまうとわかりにくくなると 考えられている。」 からくる乖離を避けよう、という話ですね。
- :memo: エバンスが、 その二つは必ず結び付けられるって前提で読んでね って言ってるだけだと思う
- :memo: 単一のモデルは、分析モデルと設計モデルを分けないという意味であると思う
- :memo: 設計とモデルが共通にできる・・のではなく、設計やモデルがどうあろうと、（選択肢はたくさんるから）対応づけを考えることは現実的である（のでやってみろ）、と理解しました
- なんでアストロラーベの話が出来たのだろう。天体を表すモデルを機械によって実装したってのはわかるのだけど:+1:
- P.47「そのため、我々は選択したモデルに対する要求をもっと厳しくしなければならない。そのモデルは全く別々の2つの目標を満たす必要があるからだ」
- この2つの目標とは、なんだろう？:+1:
- 「モデル駆動設計のアプローチは、分析としても設計としてもうまく機能するモデルを要求する」とあるので、分析と設計を分けずに両立させるということかと思われます。
- P.47それゆえ：の部分、「設計で使用する用語法と責務の基礎的な割当をモデルから引き出すこと」
- これの意味がよくわからない
- P46 「純粋な分析モデルでは、ドメインを理解するという第一の目標にさえも到達できない」という「純粋な分析モデル」というのはどういうモデルなのか。逆に、「純粋でない分析モデル」ならドメインを理解できるのだろうか？
- モデル駆動の重要さを開発メンバー全員に伝えるにはどうしたら良いのだろう

---

# モデリングパラダイムとツールによるサポート
## 目安の時間
- 18分

## 感想・気づき

- 自動生成ツールは管理できる人がいれば強力なツールだけど、管理できなくなった途端脅威になる(実感):wakaru:
- Proxyパターンだと思うが、こういったパターンを今利用している人はどれくらいいるんだろうか?
- 最近見てないから復習したい
- > 忘れないで欲しいのだが、こうしたモデルに基づく設計は一度に現れるものではない。ドメインの重要な概念を蒸留して、シンプルで鋭いモデルにするには、リファクタリングと知識のかみ砕きを何度か反復しなければならないのだ。
- 繰り返し述べていて、これが重要な意識・考え方なんだなと思う
- リファクタリングは開発効率を良くするだけでなく、モデルをより鋭くするための行為でもある:+1::+1:
- :memo: この場合の「リファクタリング」ってファウラーの「リファクタリング」とはちょっと違いそうなので注意しなきゃとは思いますね。
- :memo: ファウラーのリファクタリングは、コードに対するものに集中しているイメージ
- :memo: エヴァンスの言うリファクタリングは、どちらかというとモデルに対するリファクタリングなんじゃないかしら、的な
- 本読むときは（引用とかじゃない限り）一旦他の本や、先のことを忘れて読むといいかもね
- :memo: リファクタってモデルをコードに反映する作業で使われてるイメージでしたが、リファクタによってモデルが鋭くなるって、どういうことなんでしょう？ 反映中に辻褄が合わず、フィードバックが起きる？
- コードの修正が結果的にモデルの修正につながっていく
- :memo: コードに不吉な匂いを感じてリファクタリング→責務の分離の必要性が出てくる→モデルが蒸留される
- P.50の例3.1は、Excelマクロで頑張っている現場として置き換えると、結構通じやすい気がしている
- マクロを作った人は機能の背景を理解しているだろうが、それを他者が理解できるようにコードに反映はされていない
- P.49「オブジェクト設計の真のブレイクスルーが訪れるのは、コードがモデルにある概念を表現したとき」ただ技術面の性質を利用するだけでなく、ドメインの概念を反映してこそ真価が発揮できる。:+1:
- P.55 「モデル駆動設計は規模を容易に拡大させることができ〜」、「テストもやりやすくなる。」の部分は要するに、モデル駆動設計を行うことで変更容易性・テスト容易性を高めることができる思いました。この点はt-wadaさんの[「質とスピード」](https://speakerdeck.com/twada/quality-and-speed-2020-spring-edition?slide=20)の保守性の観点と同じだなと思いました。:+1::+1::+1::+1::+1::+1:

## 疑問

- P.48 冒頭の陰陽図みたいな図の意味がいまいちつかめていない。図の『パラダイム』は何を指しているのだろう？:+1::+1::+1::+1::+1::+1:
- :memo: パラダイムによって設計って変わるよねってだけかな
- :memo: 「モデルをどのように定義・記述するか」の方法論を指しているイメージ > パラダイム
- :memo: モデルと設計を結びつける考え方や方法論という程度でいいかと。
- :memo: モデルと設計を接続するためには、何らかの接続方法が必要だよね（一切の接続方法無しに接続はできないよね）ということで、その接続方法を「パラダイム」って呼んでるだけなイメージ
- :memo: オブジェクト指向、関数型、論理型などですね。
- :memo: 手続き型言語の接続方法　→　フローチャート図/ オブジェクト指向言語の接続方法　→　クラス図
- :memo: 多分モデル=クラス図ってイメージをまず捨てた方が良い定期
- この節が前後の節とどうつながっているのかわからない……。:+1:
- 「モデル駆動設計の大きなメリットとして、**テスト容易性の向上**がある」はオブジェクト指向ではなく、モデル駆動?
---

# 骨格を見せる：なぜモデルがユーザにとって重要なのか？
## 目安の時間
- 18分

## 感想・気づき
- > だが、ここで示しているのは、それとは別のモデルの対、すなわち、ユーザモデルと設計・実装モデルから生じる問題だ。
- ここで（おそらく）初めて、ビジネスエキスパートや開発者のモデルとは異なる、「ユーザーのにおけるモデル」という概念が出てきたなと思った
- 加えて、ここではビジネスエキスパートや開発者のモデルとユーザーに提示するモデルに差異を生じさせる「モデルの幻想」は混乱を招くのでなるべく避けた方がいいという主張だった
- 齟齬を避けるために、あえて骨格を見せる（ファイルであることを理解してもらう）アプローチも大事ということと理解。:+1:
- :memo: モジュール内部で起きるアクティビティとか？
- :memo: データ構造そのものより、ドメインへのコマンドの構造かな
- :memo: 任意の名前で保存できるはず→メンタルモデル。名前はファイルとして保存するので文字に制限がある→設計実装モデル
- :memo: なんで隠したいのかというと、ビジネスロジックとプログラミングが乖離しているから。なので、隠さなくてもいいように、する

- ユーザにとってはお気に入り。だけど、中身はただのファイルシステムだった。命名規則に間違いがあった場合、「ファイル名が間違っています」。ファイル名とは？　と混乱しちゃうのだろうと思った
- > ユーザインタフェースの中にドメインモデル以外のモデルの幻想を作り出そうとすれば
- この部分は、ユビキタス言語の章で上がっていた以下の疑問と通づるところがありそう:+1:
> OOUIなどで用いられる言語と一致させる必要はあるのだろうか？UIを通してユーザに認知されるモデルと開発者がチーム内で用いるモデルは別の方が良いのか？同じ方が良いのか？
- このあたりの議論は、システム全体を一つのモデルで表すのであれば、という前提に基づいていそう。「UIレイヤーは別の（サブ）システムである」という前提に立てば、ユーザモデルは「幻想」ではないということになるような気がする。
- ~~SoEとSoRの違い、みたいな議論のように感じた~~
- エンドユーザとドメインエキスパートの立場が同じである場合（回路設計スクリプトの例）は、UI層にユーザモデルを作り出すことは「幻想」になるが、そうでない場合、たとえばBtoCサービスにおいて、B側にドメインエキスパートがいて、C側にエンドユーザがいる場合、は「幻想」とはならない、ような気がする。
- 回路設計スクリプトの場合は前者の例であり、ブラウザのお気に入りの場合は後者の例になるので、例が恣意的すぎるのでは？
- 前章まではドメインエキスパートが理解できないモデルは問題があるという論点であったが、この章でユーザがでてきた。設計、モデル分析を行う場合に、ユーザを巻き込めと暗に伝えているのではないかと感じた。:+1:

## 疑問

- 「分析モデルと設計モデルが別々に作られること」なぜなのか?
- 実現不可能な分析モデルに何の意味があるのかわからない
- 骨格を見せるとは？
- :memo: ドメインのデータ構造のことかな？
- :memo: モジュール内部で起きるアクティビティとか？
- :memo: なんで隠したいのかというと、ビジネスロジックとプログラミングが乖離しているから なので、隠さなくてもいいように、する

---

# 実践的モデラ
## 目安の時間
- 18分

## 感想・気づき

- わかりみしかない:+1::+1::+1::+1::+1::+1:
- 「ソフトウェア開発を製造業のような構造にすることで、プロジェクトが台無しになる」
- 「ソフトウェア開発は**全てが設計**のため、責任を過剰に分離することは、モデル駆動設計の妨げになる」
- :memo:[日本のソフトウェア産業は「製造業」]( https://blog.goo.ne.jp/mit_sloan/e/5c9a3dcc58d54b986526aab19a27fa19)
- 自称ソフトウェアが書ける人をどうしたら良いんだろうか?
- プログラミング言語仕様を知っていてコンパイルできるコードが書けるだけでは駄目なんだけどな…
- 今も設計、モデル、実装する人は責任・役割を分割させて行うプロジェクトは多い(SIは特に)。なかなか、ここで主張されている事をもとにメスをいれる流れにならないなと感じた。:+1::+1:
- エヴァンスほどのエンジニアでも上流工程だけを担当していては失敗するんだから、一般人がやっても成功するわけがないよね、という感想。
- 結局モデルは実装のフィードバックを受けて成長しなければ、単なる絵に描いた餅に堕してしまう。:+1:
- リファクタリングしようと設計を練っていたが、業務に圧迫され期間が経ってからできるようになって見直すと、過去の自分と分断されたような状態になって、設計のやり直しになった悲しい記憶が...

## 疑問

- 節の後ろから3段落目にドメイン駆動設計とモデル駆動設計について説明しているが、ドメイン駆動設計の次の段階がモデル駆動設計ということだろうか？ ドメイン駆動設計でモデルを作る→モデル駆動設計でモデルの中から設計に使えるものを選んだりモデリングを再検討したりする、みたいな？:+1::+1:
- :memo: モデル駆動設計 の1つがドメイン駆動設計
- :memo: ドメイン駆動設計の中にモデル駆動設計があるんですよね
- DDDのプロセスにモデル駆動がある
- :memo: ドメイン駆動設計がモデル駆動設計の手法を使ってるということでは
- 元々モデル駆動設計とかオブジェクト指向とかは元々あった物を、それをドメインを中心にやるには、というので取りまとめたのでDDDという理解
- :memo: [ドメインもしくはドメインモデルという概念が登場する書籍一覧](https://qiita.com/j5ik2o/items/505e685b34e3ebc91009)
- P.58「開発者によるリファクタリングによって、モデルは力を増すことなく、むしろ力を失うことになる」というので、リファクタリングをしてモデルにフィードバックがうまくできてないな？　と思ったら何か危険信号なのだろうと思う。:+1::+1::+1::+1::+1:
- それをどうやって、感じ取ればいいのだろう。何か仕組み化が必要？
- フィードバックはリファクタ時より機能追加時に起きるものと思っていたので、斬新な意見でした。
- :memo: ここの節の根本的問題はコミュニケーションの分断だと思う
- :memo: みんながモデルに触れるから気づく
- :memo: 違和感に気付くには、ドメインモデルとリファクタリング結果を併せて見る習慣を付けて、歪みがないか気をつけるとかかなー。
- :memo: 「違和感」って、「あるべき形」と「今ある形」のギャップによって生まれるのだと仮定すると、自分はどんな形を「あるべき形」と捉えているのか、というのを掘り下げてみるのが、「違和感」を嗅ぎつけるための一つの手段になるのかもしれない
- :memo: 無理にがんばれば実装できる。素直に実装できないー→違和感？
- :memo: モデル駆動するチームが前提である。

---

# 感想戦

- 個人的にはモデル駆動設計の一番の障害って、チームメンバーのマインドセットがそうならない事が多き事だと思ってる。