DDD本 11章 アナリシスパターンを適用する
===
###### tags: `エヴァンス本読書会`

/poll "アンケート第2問！ >>> この章は難しかった？" "お手上げ" "日本語難しすぎない？" "ちょっと何言ってるか分かんない" "まあ分かる" "余裕でした" "読んでない(小声)" "いま読んでる（小声）"

/poll "アンケート第1問！ >>> 『DDD輪読会への参加は何回目？』" "はじめて！" "2回目！" "3回目！" "100回！" "なんかいっぱい！！！"

# Discord開始位置

-

# 自己紹介

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

---

# 第11章 序章
## 目安の時間
- 20分

## 感想・気づき
- > この時に出発点となるモデルは、すでに表現力豊かで、実装可能であり、習得するには高くつきそうな機微に対応しているのだ。
- 「機微に対応している」とは？
- 原文だと `addresses subtleties that might be costly to learn`
- [subtlety](https://www.oxfordlearnersdictionaries.com/definition/english/subtlety?q=subtlety)
> [countable, usually plural] the small but important details or aspects of something
- [address (verb)](https://www.oxfordlearnersdictionaries.com/definition/english/address_2)
- 「微妙だが重要で、しかも学習が困難な要素・観点 etc に対して、考察と対処法が一通り定義・提供されている」というぐらいのニュアンスか

- > p.299 そこから、リファクタリングと実験を行う。これは、そのまま使える既成の解決策といったものではない
- > P.300 アナリシスパターンは技術的な解決策ではなく、特定のドメインでモデルを考え出すのを支援する手引である
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822797537316175880)
- そのまま使うのではなく、そのパターンから類似点とかを見つけていくような感じなのだろうか
- 一定の枠組み（＝パターン）からスタートして、そこから自分の問題を解決するために最適な形を発見するためにアナリシスパターン（他、既存のパターン）が使えるよ、ということかなと:+1::+1:
- 本書後続の文章でも「こういうパターンは(...)非常に有益な出発点を提供する」という記述あり :+1:
- > 役に立ちそうなパターンを特定したら、試してみると良い。筆者の経験では、パターンの動作を本当に理解するには、自分の問題に当てはめて試してみるしかない。(...)パターンが自分の要求に正確に当てはまらなければ、躊躇せずパターンを変更すること。パターンは提案であって、処方箋ではない。 - 『アナリシスパターン』 p.11-12
- > パターンは注意深い思考の蓄積である。それらが筆者のモデリング作業の頭出しとなるように、読者にとってもそうであることを望む。大切なことは、それらが開始点であり終着点ではないことを意識することである。 - 『アナリシスパターン』 p.13

- > P.300 このアナリシスパターンという名前からは残念ながら伝わらないのが、これらのパターンには実装に関する意義深い議論があり、ある程度コードも含まれているということである。
- 名前から想像するに、分析モデルみたいな感じにとらえて、コードとは全く関係ない世界を考えてしまうのを危惧している感じ
- > P.300 このコンテキストから外れてモデルの考え方を議論すると、適用は困難となり、分析と石器江との間に致命的な溝が生じる危険がある
- まえがきにあった、3つ目のモデルを重視しすぎてしまったプロジェクトを思い起こさせる
- 第3章と併せて読むと良さそう
- > モデル駆動設計は、分析モデルと設計という二分法を捨て去り、両方の目的に使える単一のモデルを探し出す。 - 本書 3章 「モデル駆動設計」
- > ソフトウェア・システムの一部を設計する際には、紐付けが明らかになるように、ドメインモデルを文字通りの意味で忠実に反映させること。 - 本書 3章 「モデル駆動設計」
- > コードを作成する人々がモデルに責任を感じていない場合や、アプリケーションのためにモデルを機能させる方法を理解していない場合、そのモデルはソフトウェアと無関係になってしまう。(...)モデラが実践プロセスから切り離されている場合、実装に伴う制約に対する感覚を、モデラは習得することがないか、できてもすぐに失ってしまう。 - 本書 3章 「実践的モデラ」
- > モデルに貢献する技術的な人はだれでも、一定の時間をコードに触れることに費やさなければならない。 - 本書 3章 「実践的モデラ」
- 分析・モデル・設計を切り離すのはEvans的にはNGで、Fowlerの『アナリシスパターン』は名前だけだと分析だけ扱ってるっぽいけど、実際は違うし違うからこそ援用しているんだから勘違いするなよ、的な意図での言及かもしれない:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822799423767576587)
- ドメインはサービス毎に異なるので、モデリングをして実装に落とし込むという作業はパターン化が難しく、スキルの差別化になると思っていた。が、アナリシスパターンのようなものがあるとなると、そうではないのかもと焦りを感じた。
- 先人の見出したパターンをたくさん引き出しとして持っていて、かつ応用的にモデリングできるということが、スキルの差別化になっていくのではないかと。
　　- なるほど。たしかにそうですね。ありがとうございます。

## 疑問

- DDDに限った話ではなくても良いのですが、アナリシスパターンを実装の参考にしたよ、みたいな方っていらっしゃいますか？:+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822795041558757379)
- > P.301 この設計は機能するが、使い方はぎこちなく、変更するにも注意が必要で、意図をうまく伝えていない。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822794514992463882)
- 資産と各計算サービスの設計は9章か10章のあたりでリファクタしていた気がしてるんですがそれはなかったことにしてるという認識であってるんでしょうか？
- この章では、別のアプローチでのリファクタリングとして、言及されているのだと思います。:+1:

---

# 例11.1 利息を得る　勘定を用いた場合
## 目安の時間
- 20分

## 感想・気づき

- アナリシスパターンを適用してみた、という話だったけど、このあたりのモデルを一部適用した感じかな
- トランザクションが会計取引
- エンティティが仕分記帳？
- P302仕訳記帳(Entry)→アナパタのエントリでよさそうですね


- P.305の図11.6を見て、最終的にアナリシスパターンにあった会計取引を止める話から、いろいろと学べる
- アナリシスパターンをそのまま適用とするのではなく、議論のきっかけにしている
- 「本だと会計取引というのは〜」「でもこのシステムが表現しようとしているドメインでは〜」

## 疑問

- P303-304 会計取引はエントリが移動元と移動先でプラマイゼロになる制約を持っている(アナリシスパターンの会計モデルはお金やモノの移動を追跡するモデル)。のが、このドメインでは発生という概念もあり、そう単純に扱えない。→このドメインに不要な概念が削られて、別のモデルにかわっていく。という感じ？:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822800677695651840)
- 会話読み解くのが難しい・・・
- :memo: 会計ドメインの知識が無いと、どう扱うのが適切なのかがわからない、あるいは、会計業界の標準知識と整合させられない、みたいな難しさがある。 というのは、各業務ドメインであるある。
- :memo: この章では、まずは『アナリシスパターン』記載のパターンを足がかりとして、目前の会計ドメインへの理解を段階的に深めていって、「発生」という会計ドメイン一般の概念にたどり着くまでのストーリーを語っているのかなあと
- :memo: こういう業務ドメインの基礎知識は、ドメインエキスパートと会話するのに必要になったりしますよね。
- :memo: 共通概念を持てないと、スタート地点からすりあわせないといけなくて難しい、という。

---

# 例11.1（続き） 夜間バッチについての洞察
## 目安の時間
- 20分

## 感想・気づき

- > P.308 依存関係の設計において、最も注意を要する部分の1つは、更新のタイミングと制御である。Fowlerは、次の3つの選択肢について議論している
- この3つは、アナリシスパターンのP.113-114にある6.7.1〜6.7.3に書かれている方式のことを指しているみたい

## 疑問

- > P.309 例えば、収入に対して20%の源泉徴収を記帳するということです。でも、私たちのケースでは、これは単純で、記帳されるのは常に総額になっています。
- そもそも全体的に会計の話が分かっていないんですが、総額の記帳と20%の源泉徴収を記帳する場合の違いは源泉徴収の計算をした後の値を記録するのとひかれる分の値を記録するかの違い、という認識であってますか？ :+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822804371209060372)
- :memo: アナリシスパターンは、会計知識としてどうあるかを表現していて、その知識では記帳ルールが計算するので、元の金額と源泉徴収額がわかるようにあつかう。 ここではそれは単純化したシステムを想定しているので、計算結果だけを記帳すれば十分、ということかと。
- :memo: 補足として。やはり「メソッド」は会計方法のルール集であって、だからそのメソッドの一つ一つが「概念としては、メソッドが記帳する金額を計算する」という言及がされていますね。

---

# アナリシスパターンは活用すべき知識である
## 目安の時間
- 20分

## 感想・気づき

- > P.312 運よくアナリシスパターンがあっても、それが具体的な要求に応えてくれることはほとんどない。だが、アナリシスパターンは、調査に対して有益な手がかりを与え、明確に抽象化された語彙を提供してくれる
- > P.313 アナリシスパターンは、最も重要で困難な意思決定に焦点を合わせ、代替案や選択肢を浮かび上がらせる
- DDDでの立場からだと、アナリシスパターンは有益ではあるけど、それがそのまま適用できる状況は稀であると言っているけど、それでもアナリシスパターンの中で語られている結果や背景にある理論が車輪の再発明にならずに有益であるとのこと:+1::+1::+1:

- 章全体を通して読んでみて思うのは、アナリシスパターンという先人の体系立てられたモデルとそのモデルとなった背景の理論を目に通し、部分的に適用してみて、いま自分たちが直面しているドメインとの差分はどうなのかと考えるきっかけづくりの道具のように思える。:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822809224231780432)
- だから、たとえばドメインに詳しい誰かがモデルを作ってみました。ほうほう、なるほどなるほど。だけでは駄目で、どうしてそんなモデルにしたのか、という意思決定の背景と、実装するにあたってのトレードオフとを出していかないと、アナリシスパターンみたいな（少なくともエヴァンスの言う）有用な形にならないのかもしれない。
- 逆にそういうものがちゃんと提供できれば、いろんな現場のパターンが抽出できそうな気がする

- 全体を通じてアナリシスパターンを読んだことがない＆会計基礎知識がない、ので会計の言葉を調べながら読んでるうちに、わかったんだかわからなかったんだかわからないような状況で読み終えた感じでした:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/822808947659898881)

## 疑問

- アナリシスパターンみたいなもので、他に取り入れられそうなやつってありそうですか？（ビジネスパターンによるモデル駆動設計で紹介されているようなやつとか）:+1::+1::+1::+1::+1::+1:

---