DDD本 10章 しなやかな設計
===
###### tags: `エヴァンス本読書会`

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

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

# Discord開始位置

- [2021/02/20 Sat](https://discord.com/channels/432531367427964929/740202765619429487/812535575285727253) : 前半
- [2021/03/06 Sat](https://discord.com/channels/432531367427964929/740202765619429487/817667520072777750) : 後半

# 自己紹介

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

---

# 第10章 序章
## 目安の時間
- 15分

## 感想・気づき

- > P.247 開発者が、処理の中に暗黙的に含まれているものを完全に予測する自信がなくなると、すぐに重複が起き始める
- わかりみしかない:+1::+1::+1:
- > P.248 ソフトウェアの設計が明確でないと、開発者は現在の混乱した状態に目を向けることさえも恐れ、ましてや変更を加えるなどもってのほかだと考えるようになる。:+1::+1:
- 調べる時間が無いと特にそうなる傾向だと思う。
- よくわからないからと、元の設計と関係ない実装が行われたりするケースも恐ろしい。
- > P.248 過去に作成したレガシーによって押しつぶされないようにし、開発の進行に合わせてプロジェクトを加速させるためには、楽しく仕事ができて変更を呼び込むような設計が欠かせない。それがしなやかな設計である。
- 「変更がしやすい」ではなくて、「変更を呼び込む」がポイントに見える。従来の保守性とは違って、ビジネスの発展に追従できるような変更。もしくは8章のブレークスルーのシェアパイのような、設計で見つけたモデルをビジネスの売り文句として取り入れることができる。前向きな変更容易性。:+1::+1::+1:
- 楽しく仕事ができて変更を呼び込むような設計がしなやかな設計と言われても全くよくわからん:+1::+1:
- 今更だけど、エヴァンス本で想定されるプロジェクトは、同じサーバサイドの領域でもドメインロジック開発者とクライアント開発者と分かれて開発するような状況っぽくて、サーバサイド全部面倒見ます、的なチームがこの本を読むとピンと来なかったりするのではないのかな。
- > P.248 だが、シンプルに作るのは容易ではない。
- シンプルとイージーは違うよ、みたいな。
- > P.249 複雑さによって進捗を阻まれているなら、最も重大で難解な部分を磨いてしなやかな設計にすれば、レガシーの保守に飲み込まれることなく、複雑さの限界を打ち破れるようになる。
- そうですよねと思いつつも、そうは言っても難解な部分に手に入れるのは大変...:+1::+1:
- 全体通して読んでて思うのは、カプセル化をちゃんとして、中身の実装を追わなくてもちゃんと使えるようにしよう、ということに帰結している気がする。:+1::+1::+1::+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812648835415015444)
- それがとても難しいことなんだけど…。
- :memo: 略語は悪い文化

## 疑問
- P248 「扱う人に対して本当に力を与えるソフトウェアがどのような設計になっているか、調べてみるといい。」とさらっと書かれていますが、良い設計をどうやって調べたり、判断したりしていますか？(良い設計の調べ方が本章のテーマだとは思いますが・・・):+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812646120974843924)
- :memo: 自分よりできそうな人におすすめされた本を読んだりですかね
- :memo: 当時は良い設計だったが今となっては、みたいなものを参考にしても良いかどうかみたいな話ですが
- :memo: フレームワークのコードも後方互換性維持するために汚なくなってたりする気がします
- :memo: 良い設計と良いコードは別
- :memo: ビジネスドメインを実現するための設計は、おそらくパフォーマンス以上に意味論を重視すると思うので、「このコードの目的は何」というのを履き違えると、誤った学習をしてしまう恐れがありますよね
- :memo: 事前に無文脈に「良い設計」が手に入ると思うと、いささか危険な気がします(その意味で、このエヴァンスの言はちょっと怪しい気がします)

---

# 意図の明白なインタフェース
## 目安の時間
- 15分

## 感想・気づき

- > P.251 我々は常に、認識の過負荷と戦っているのだ。
- よくわかる。過負荷を減らしたいとは常々思っているけど、過負荷を減らす為の取り組みはそこまでできてないかも。:+1::+1:
- > P.251 ある開発者があるコンポーネントを使用するために、その実装についてじっくり考えなければならないのであれば、カプセル化の価値は失われる。
- カプセル化ほんと重要:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812653311903793222)
- :memo: 金額を BigInteger のまま扱わない、に通じる話かな
- :memo: Map<String,String>が引数だと辛い
- :memo: なんでも入れる気満々. Map<String,Object> とか
- > P.252 設計におけるパブリックな要素がすべて集まってインタフェースを構成しており、こうした要素の名前によって、設計の意図を明らかにする機会が与えられる。型名、メソッド名、引数名が、すべて組み合わされて、意図の明白なインタフェースを形成する
- 型名、メソッド名、引数名すべてを組み合わせて、という下りを読んでいると、メソッド名だけで表現するのではなく、型名、引数名でもValueObjectを使って、それらすべてで意図を明白にする、という考え方っぽい:+1:
- メソッド名に完全名を与えてなんとか意図を表現しようとする試みをしていたけど、戻り値、引数の型、引数名もすべて組み合わせて表現しようとすると、表現の幅が広がりそう
- これまでメソッド名だけで表現しようとしてきたが、戻り値の型、引数の型も表現手段として利用することで、作成者の意図がより明白に表現できそう。:+1:
- テスト駆動などでクライアント開発者視点から見て、インタフェースがわかりやすいかどうか見るのは、有益そう。:+1::+1::+1:

## 疑問
- 関数名や変数名が大事なのはその通りだと思うのですが、英語が苦手なのもあって名前付けに凄い時間がかかる。個人的には、名前付けってコーディングや設計で一番時間かかる工程のような気もします。命名に悩んだときに、良い指針とかチェック項目とかがあれば教えていただきたいです。:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812650110021795850)
- 日本語コーディング？
- :memo: 思いついた単語のsynonymとantonymを調べてます
- :memo: 名前づけに迷うことが、何かがブレてる悪い兆候
- :memo: 英訳することでユビキタス言語から意味がそれていくの怖い感あります。
- :memo: 日本語+命名してみたやつで意味が通じるか他の人に相談しますね
- :memo: 「マクドナルドメソッド」ってのを聞いたことがあります。悩んでいるならぜったいに意味がわからない名前をつける。(jklfdjsklfjsalkfj とかまずつける) そうすると正しい名前をつけなくては！って意識が高まり微妙な名前が残り続けることが減ると。

---

# 副作用のない関数（SIDE-EFFECT-FREE-FUNCTIONS）
## 目安の時間
- 15分

## 感想・気づき

- > P.255 操作は大きく2つのカテゴリに分けられる。それが、コマンド（command）とクエリ（query）だ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812654670614495242)
- まだDDDを学び始めの頃、この話を読んで、たしかにそうだって思った記憶。
- これらを意識できるだけでも違う気がしている:+1:
- :memo: メイヤーを参照しているので、ここではCQRSというよりCQSぐらいのお話でしょうね
- :memo: CQSはメソッドを分ける、CQRSはそもそものモデルも分ける、ぐらいの理解
- :memo: [CQSとCQRSの違いはメソッドの分離かモデルの分離かという観点](https://qiita.com/hirodragon/items/6281df80661401f48731)
- > P.255 操作によって影響を受ける、きわめて意図的な変更を表すのに、なぜ副作用という言葉が選ばれ、使われたのだろうか？　それは複雑なシステムでの経験に基づいてのことではないかと私は思う。ほとんどの操作は他の操作を要求し、呼び出された操作がさらに別の操作を呼び出す。この恣意的な深いネストがあると、ある操作を呼び出したことの結果をすべて予想することが非常に難しくなる。クライアント開発者は、ネストの2層目、3層目の操作による影響を意図していなかったかもしれない。そうした影響が、語のあらゆる意味において副作用になったのである。
- エヴァンスの推測も入っているが、この感覚は非常にわかる。
- 人、もしくは言語によっては画面に表示（print）さえも副作用と言うけども、意図的な変更を表しているのに、なぜ副作用なのか？　という疑問に対しての1つの答えだと思う
- そうは言われても、たぶん納得できない人はいると思うけど、そういった背景があるんだ、くらいは知っておけば。
- 元々、「関数という抽象化」というコンテキストにおいて、計算結果の返却以外の作用は関数の挙動ではないから「副作用」と用語が定義されたので、「ソフトウェアの目的にあった意図的なものか否か」はまったく関係ないでしょう。
- > P.255 副作用を起こさずに結果を戻す操作は、関数（function）と呼ばれる。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812655490189361162)
- 節のタイトルが「副作用のない関数」と言っていたから、関数には副作用があるものとないもので分けられるのかと、最初は受け取ってしまっていた。:+1:
- でも「関数」自体が副作用の無いものと定義されている。
- 一般的に言われている関数は処理をまとめたものと捉えられているケースの方が多そう。副作用の議論はDDDだから・・・ではないのをググってみて知った。:+1:
- :memo: 「関数＝副作用がない」という定義は、あまり一般的では無いような気が。 だったら、なぜ「純粋関数」という言葉がわざわざ用意されているのかな、という
- > P.256 値オブジェクトは不変である。このことは、生成時にのみ呼び出されるイニシャライザを別途すると、すべての操作が関数であることを示唆している。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812657109044035625)
- 言われてみたらたしかに、と思った。:+1:
- モデルを見て、エンティティと値オブジェクトどちらにするか迷ったときには、値オブジェクトとして実装する方が良さそう。:+1:
- :memo: identityを必要とするかどうかで判断するのでは？
- :memo: 「エンティティと値オブジェクトどちらにするか迷ったときには、値オブジェクトとして実装する方が良さそう」 → 車をエンティティ、タイヤは？とか考えるときに悩んだ記憶
- :memo: エンティティと値オブジェクトの間は所与で決まるのでなく、まさにドメイン（＝知識・関心事・活動）によって定義されるという好例っぽい > タイヤ
- > P.256 しかし、当然のことだが、このように副作用を分離して単純なコマンドメソッドにする方法は、エンティティにしか適用されない
- 最近の言語とかだと、オブジェクト自体がイミュータブルなものもあるので、コマンドメソッドと言いつつ、値をコピーして一部変更した別のオブジェクトを返す、ということはありそう
- 最近だと、この[質問箱](https://github.com/little-hands/ddd-q-and-a/issues/329)の話があった
- > P.256 副作用のない関数、中でも不変な値オブジェクトに置かれたものは、操作を安全に組み合わせることができる。関数が意図の明白なインタフェースによって示されていれば、開発者は実装の詳細を理解していなくても、その関数を使うことが出来る
- 例10.2 にある PigmentColor.mixedWith()の定義が意図の明白なインタフェースによって示された副作用のない関数として、わかりやすかった。
- `PigmentColor mixedWith(PigmentColor other, double ratio)`

## 疑問

---

# 表明
## 目安の時間
- 15分

## 感想・気づき
- > P.263 このプログラムは追加された塗料の混ぜ合わせる前の一覧を帳票として出力している。
- > P.264 ここまで来ると、コマンドはmixIn()だけである。このメソッドはオブジェクトをコレク
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812662387340869642)
- mixin()関数をコレクションにする流れは、いいなぁって思う
- mixin()関数の様な設計を自分でできる気がしない。。現実世界では、塗料を混ぜたら一つになってしまうし、履歴が欲しいなら別途履歴情報を持つ設計にしてしまいそう。:+1::+1::+1::+1:
- ドメイン知識とは、現実の物と同じ構造ではなく、抽象化された概念であるっということなのかな・・:+1:
- もし混ぜ合わせる前の一覧をだす要求がなかった場合は、どのような設計なるのか気になりました。:+1:
- 副作用を無くすのであれば、混ぜ合わせたオブジェクトを生成して返す関数とか思いつきましたが、それはmixinではない様な気がします。
- ドメインとして自然なIF　vs　副作用がない関数IFの対立って生まれないのかな？

## 疑問

- P.250の設計パターンの図にある、副作用のない関数と表明の関係性がいまいちわかっていない。合成を安全にする、というのはどういうことだろう:+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812660399030927390)
- 取り置き塗料が生まれ、それをmixInでリストで保持した段階で安全になったと表現しているように見えました
- :memo: 合成を安全にするものとして副作用のない関数はそもそも安全に合成できて、副作用があるやつについては表明で安全にできるよ、って話だと思いました
- :memo: Siena.今日 21:25
(副作用のない)関数はシグネチャでの合成可能性を保証し、表明は値・状態についての変化範囲を保証するので、補完関係にあると思います。
- 皆さんの現場では表明を使っている？　どんなふうに書いている？:+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812658652905078825)
- :memo: テストケースを実装することで表明することが多いかなぁ
- :memo: 本が昔なので、実際はUnitテストな気がします。(引用されている本ではAssert()をつかうのがいいよ、って感じでした。多分)
- :memo: 確かに最近、Design by contractって言っている人減ったきはする
- > P.262 不変条件と事前条件、事後条件を明確に述べることによって、開発者は操作やオブジェクトを使用した結果を理解できるようになる。理論上、矛盾のない表明の集合はすべて機能する。しかし、人は、頭の中に述語を溜め込むだけではない。モデルの概念を推測したり、補ったりするので、アプリケーションの要求を満たすだけでなく、人にとっての意味のあるモデルを見つけ出すことが重要だ。
- この文の「しかし〜」から繋がる話がよくわからなかった。言っていることはわかるけど、前半の話とどう繋がっている？
- > P.262 凝集した概念が集まったモデルを探し求めること。それも、意図された表明を開発者に推測させ、学習効率を上げながら、矛盾したコードが作られるリスクを小さくするものでなければならない。
- ここの文の意味がよくわからない。:+1:
- 意図された表明を開発者に推測させることが、どう学習効率を上げることに繋がる？

---

# 概念の輪郭（CONSEPTUAL CONTOURS）
## 目安の時間
- 15分

## 感想・気づき

- > P.266 さらに悪いことに、概念が完全に失われかねない。ウランの原子を半分に分けたら、それはウランではない。もちろん、重要なのは単なる粒度ではなく、その粒がどこで活動するかである
- ●●一覧画面別、●●詳細画面、それらに対してCRUDな機能を別々で作るような現場を見たが、それによって内部ロジックの食い違いが起きてしまったことを思い出した。
- > P.270 このように簡単に拡張できたのは、開発者が変更を予期したからではない。また、設計の用途を非常に広くして、考えられるどんな変更にも対応できるようにしたからでもない。以前のリファクタリングによって、設計がドメインの根底にある概念をとらえたからである。
- 概念の輪郭というのがわかりづらいが、意味のある単位（＝高凝集？）にまとめて分解することで、それに基づいたコードにしておくことで、いざ予測不可能な変更が発生したとしても、変更が検討しやすいことかな。
- 概念の輪郭というと、境界を決めて余計なものを削ぎ落とす話ばかりかと思っていたが、意味のある単位であれば、敢えてまとめることでドメインに紐づいて理解しやすくなることにも触れられていて良かった。:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812663856462954496)
- 「概念の輪郭」は conceptual 〜 なので、「概念的輪郭」とした方が意味が取りやすく感じた。
「新しく理解された概念や要求にコードが適合するにつれ、概念の輪郭が姿を現す。」とあるように、見出された概念ではなく、まだモデルには明確に見出されていないけれど、ドメインを深く潜るとそこに存在するような「もやっとしたなにものか (概念レベルの輪郭が感じられるなにものか)」を指しているような印象。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812671173149327370)

## 疑問

---

# 独立したクラス（STANDALONE CLASSES）
## 目安の時間
- 15分

## 感想・気づき

- 全体的に読んでいて本当に独立したクラスというのができるのだろうか？　と思ってしまった。整数とかの、言語の組み込み型のクラスが独立したクラスとなり得るのだろうか。
- > P.272 目標はすべての依存関係を取り除くことではない。本質的ではない依存関係をすべて取り除くことなのだ。
- これは同意。常に2つのオブジェクトを操作して使わなければいけないものは、1個にまとめることができるだろうし、相互依存していそうなところも、なにかおかしいと精査した結果、片方向の依存になることもあると思う。:+1:
- P.271 『暗黙的な概念の方が、明示的な参照よりも負荷を大きくする。』という考え方がクラス以外のあらゆる箇所で使える超有用な考え方だと思う。
クラスであれ変数であれ何であれ、名前から、または名前そのものを類推しないといけなかったりすると、それだけで認知的な負荷が高まって修正どころかコードを読むことすら難しくなる。:+1::+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/812666541182156851)
- :memo: ユビキタス言語になっていないということですね
- :memo: http://www.principles-wiki.net/glossary:mental_grouping
- :memo: 「i は〇〇で、xは☓☓で、yは□□で……」と、脳内でいちいちマッピングしながら読まないといけないのは辛いので、そもそも○○・☓☓・□□という言葉をコードでも使おうね、という
- :memo: 「独立したクラス」? 他に依存しないクラス。他からは依存される
- :memo: 依存 = 前提知識でもあるので、それが少ない = 依存が少ない = より前提が少ない = より独立に近いなら、単独で理解しやすいし取り扱いやすいよね、的な理解です
- P.272 『概念を明示的にし、両者の間の関係性を蒸留する』という言葉に開発者間の共通の概念がプログラミングできる利点を感じる。
- :memo: 概念の輪郭
- :memo: 「概念の輪郭」は conceptual 〜 なので、「概念的輪郭」とした方が意味が取りやすく感じた。 「新しく理解された概念や要求にコードが適合するにつれ、概念の輪郭が姿を現す。」とあるように、見出された概念ではなく、まだモデルには明確に見出されていないけれど、ドメインを深く潜るとそこに存在するような「もやっとしたなにものか (概念レベルの輪郭が感じられるなにものか)」を指しているような印象。全部読んでないから違うかもだけど。

## 疑問

---

------------------------------------

=========================== 後半ここから =============================

# 閉じた操作（CLOSURE OF OPERATIONS）
## 目安の時間
- 22分

## 感想・気づき

- お金や時間も閉じた操作になるのかな
- 時間と時刻で違いが出るし、10:00-12:00は2.0hみたいな表現が出来るからまた違うのかな。（2.0hは時間の文字列の別表現という扱いにできそうだけど）
- 10円 + 20円は30円で、「円」という（ある種の）型は変わらないので、閉じた操作ができると言って良さそう
- 多国通貨の場合は？というのはTDD本の一章が参考になりそう
- 多国通貨であっても「閉じた操作」にできる例（「できる」と「すべき」はまた違うけど）
- 時間は「閉じた操作」ができると思う。2h + 4h = 6hと（ある種の）型は維持されるので。
- 10:00~12:00 と 2.0h は、また別の型では。2.0hには「x時から」「y時まで」といった情報が無いので、情報量が違う
- 前者は「時間」ではなく「時刻間」と言ったほうが適切そう。10:00~12:00という「時刻間」を「時間」に変換したのが2.0hというような
- 時刻 (一点), 期間 (範囲/区間), 時間 (長さ, 多義的なので文脈に注意):+1:
- > p.274 ある操作が抽象的な型の下で閉じていることもある。その場合、具体的な引数は別の具象クラスでもよい。結局、加算は実数の下で閉じていて、実数は有理数と無理数のどちらでもよいのだ。
- このたとえはわかりやすい
- > p.275 戻り値が実装側と一致するため、フィルタを連続させてつなぎ合わせることもできる
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817724704009486386)
- わかりやすさとは別の利点として、メソッドチェーンをすることができるのはとても有用な点だと思う:+1::+1::+1:
- そういえば、リレーショナルモデルでも閉包性（クロージャ・プロパティ）と言っているから、SQLも閉じた操作になるのか。
- [データベース実践入門](https://www.amazon.co.jp/dp/B07JGK82RR/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)あたりを読んでいると、リレーショナルモデルと述語論理の話が出ているから、通じる話もある気がしている
- 同様の概念ですね。一般に、あるデータ型に対する演算が同じデータ型を結果とするとき、演算が閉じている、と言ったりします。
- (関係モデルは演算が閉じているけれど、SQLは閉じてないです)
- > P.275 混乱した開発者がたった数人いるだけで、プロジェクトは目標から逸脱してしまう。
- 現実は厳しい...:+1::+1::+1::+1::+1::+1:

## 疑問

- > p.273 エンティティのライフサイクルはドメインにおいて重要であるため、問いに答えるために新しいエンティティを魔法のように素早く生成することはできない。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817720045747568660)
- これの意味がよく理解できてない。状態を持っているから、問い合わせした結果の新しいエンティティを返すのが難しいってことだろうか。問い合わせではなくて、状態を変えるCommandばかりを持っているから？:+1::+1::+1::+1:
- 人エンティティがあった時に、誕生（生成）はとても意味のあるイベントなので、関係ない操作で都合良く人を誕生させるのは変ってことかなと思いました。:+1:
- 数学の閉じた操作って概念ってこれのことだろうか？
- https://nipponkaigi.net/wiki/Closure_(mathematics)
- > p.275 それでも、モデリングと設計のスキルを養う意欲のあるチームにとって、これらのパターンとそれを反映している考え方によって生み出されれるソフトウェアは、開発者が作成と作り直しを繰り返しながら複雑にしていけるものなのだ
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817722704668786689)
- 文脈からポジティブな印象を受けるのだが、最後に複雑にしていける、というのはいったいどういう意味なのだろう。簡潔になるとか、そういうわけではない？👍
- 高度なものとして成熟させていける、くらいの意味合いかと
- 原文と比較すると、本文の訳があやしいきがする
- > That said, for the team willing to cultivate its modeling and design skills, these patterns and the way of thinking they reflect yield software that developers can work and rework to create complex software.
- `these patterns and the way of thinking they reflect` yield `software that ~` という主述関係っぽい？
- だとするなら、「これらのパターンと、それらが考え方を反映する方法は、開発者が複雑なソフトウェアを作るために作業したり、手直ししたりすることが可能なソフトウェアを生み出す」という感じ？

---

# 宣言的な設計
## 目安の時間
- 22分

## 感想・気づき

- 宣言的な設計でいくつかアプローチがあって、モデルの特徴から自動生成する、ルールベースプログラミング、DSLというのがあるのかな。
- DSL自体は宣言的なものか手続き的なものかとは独立
- > p.277 また、価値があるのは、アプリケーションとモデルが同じ言語でシームレスに実装されている点だ。
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817727970655207434)
- ユビキタス言語とアプリケーションが同じ言語で使われている、ということを言っているのもあると思うけど、英語圏の人たちは特にその恩恵にあずかっているんだろうと思う。英語⇔日本語でそもそも分断が起きているよね:+1::+1::+1::+1::+1::+1::+1:
- DSL＝ユビキタス言語だと思っていた・・・。:+1::+1:
- > モデルを改良するためには、開発者は言語を修正できなければならない。この時の修正対象には、根底にあるクラスライブラリだけでなく、文法の宣言や、その他の言語解釈機能も含まれるかもしれない
- もしかして：Smalltalk
- もしかして：Ruby
- もしかして：LISP

## 疑問

- よく言語の特徴にDSLが作りやすいんですよーと聞くことがあるけど（ScalaとかKotlinとか）、どうして作りやすいのかっていう理由がよくわかっていない。（単にDSLってなんだ？　ってのがわかってないだけなのかもしれないけど）:+1::+1::+1::+1::+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817725593306136607)

---

# 設計の宣言的スタイル
## 目安の時間
- 22分

## 感想・気づき

- p.278 しなやかな設計により、クライアントコードは設計の宣言的スタイルを使えるようになる
- 今まで紹介してきたパターン（意図の明白なインタフェース、副作用のない関数、表明など）を組み合わせることで、しなやかな設計に貢献できる→宣言的スタイルを使えるようになる、ということなのかな。
- 第3部序章p.193に、「設計にいくつかの特徴をもたせることで、変更するのも使用するのも、より容易になる」と書かれている。いくつかの特徴というのが、これらのパターン？
- 前半で読んでいたのは、しなやかな設計に貢献する構成要素のお話で、この節あたりからは、それらを組み合わせてどうやってしなやかな設計にしていくのかを説明しているのか。
- > p.278 これらの論理演算は述語の下で閉じているから、仕様の組み合わせは閉じた操作となる
- 副作用のない関数でもありそう:+1:
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817733871227371521)
- p.279の通気設備つき、かつ、強化型を表すのに新しい`ContainerFeature`を追加するのではなくて、`and()`で表記するのってすごくスマート:+1::+1::+1:
- > p.283 (29ページ)に示した対話例では、開発者は仕様の「satisfied by」のふるまいを明らかに実装していなかった。その時点まで、仕様は注文のために構築する目的でしか使用されていなかった。それでも抽象は元のままだったし、機能の追加も比較的容易だったのである。パターンを使用するということは、必要もない機能を構築するということではない。概念が混乱しない限り、機能は後からでも追加できる
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817730910358077460)
- この節で「仕様を拡張する」と言っているとおり、概念さえちゃんと整理しておけば後から機能を追加していける、ということを示しているっぽい。:+1::+1::+1::+1::+1::+1:
- > P.278 宣言的スタイルで仕様を拡張する
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817731952257007626)
- 読み終えた思ったのは、ビジネスが伸びて利用が伸びて利用者が伸びて、利用者の中にサービスの理解が深まってくると、利用者の要望も「仕様」を理解したフィードバックになってくることが想像される、その時にその想像で作成された「仕様」はおそらく既存の「仕様」の組み合わせのアイディアだ、それをサービスに表現する時に「固い設計」だと多分きついんだろうと思った。:+1::+1::+1:
- 仕様と仕様の包含関係は、実装したことも必要になったこともあまりないけど、面白い
- 論理述語的なオブジェクトが、ある種の論理記号的な演算がそのまま可能になっている感じ

## 疑問

- > p.277 Scheme プログラミング言語では、ドメイン特化言語と非常に似たものが標準プログラミングスタイルの一部になっている
- Scheme 知らないのでどういうことか知っている方いたら教えてほしいです:+1::+1::+1::+1::+1::+1::+1:

---

# 攻める角度
## 目安の時間
- 22分

## 感想・気づき

- p.293 の図10.20でシェアパイがシェアをまとめた、一つの値オブジェクトになっていることがわかる:+1:
- > p.295 シェアパイの設計によって、ローンのコードで宣言的なスタイルが使えるようになった。これによって作り出されるコードは、設計としてではなく、ビジネスにおける取引の概念的な定義のように読める
- このような設計にするコツは、手続き的なコードの中から意味を細分化するイメージだろうか。（シェアの足し算をコードとして表現するにはどうする？　みたいな）

## 疑問

- > p.296 よく知られた形式主義によって、プロトコルが把握しやすくなる
- 数学以外に他によく知られた形式主義ってなんだろう？:+1::+1:
- 時間の計算とか？
- p.297 最後らへん
> その影響が及ぶ範囲は、特定のモデリングや設計の問題を超えるかもしれない。:+1::+1:
とあるが、モデリングと設計以外への影響があまりピンとこない。
こういうところじゃない？って思い浮かんでる方いますか？？
- [discord](https://discord.com/channels/432531367427964929/740202765619429487/817737023468863510)
- :memo:「a specific modeling and design problem → 具体的にこの部分をどうモデリングする、設計する」におさまらず、他の部分にも波及するかも知れないし、そもそものドメインモデル自体を見直す、ビジネスプロセスなども改革が必要かも知れない、くらいに妄想した。
- > p.296 完全に独自にプロトコルを、金融用語に基づいて考え出すこともできた。原理上は、しなやかにすることができただろう。
- ここでの「しなやかにする」はしなやかな設計にすること？？？:+1:

---