セキュア・バイ・デザイン 第12章 レガシー・コードへの適用
===
###### tags: `セキュア・バイ・デザイン読書会`

# 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です。

---

# 第12章 序章
## 目安の時間
- xx分

## 感想・気づき

## 疑問

---

# 12.1 レガシー・コードのどの部分にドメイン・プリミティブを適用するのか？
## 目安の時間
- 22分

## 感想・気づき

> p.434 ほとんどの開発者は、ドメイン・プリミティブを使うことは合理的で、直感的に分かりやすい設計であることに異論はないかと思います。

- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010511833435746397)
- 確かに分かりやすいが、チーム内で理解を深めて使っていく想像はまだできなかった。コード読みにくいね～とか問題が共有されてきたら、この章の方法使う感じかな。:+1::+1:

> p.434 汎用的なデータ型をドメイン・プリミティブなどの明示的なデータ型に置き換える理由は、好みの設計にするためではなく、型による統制を図るためでなければなりません。そのためには、境界付けられたコンテキストと意味的境界を識別するとこから始めなくてはなりません。

- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010513310967410738)
- 同じ「注文」という言葉でも、人によって意味することが変わってくるのが意味的境界:+1:

## 疑問

---

# 12.2 メソッドやコンストラクタの曖昧な引数
## 目安の時間
- 22分

## 感想・気づき

> p.442 この検出によるアプローチは、データの質に問題があり、安全な実装を施したことで、現状の運用を破綻させてしまうことを避けたい場合に効果を発揮します。
- 問題のある質のデータを受け入れること自体で問題が起きないかという気がしてくるが、実際に「これを受け取るのはまずいけど、一旦ログだけ出してうまいこと処理させよう」みたいな対応があったような記憶も。 :+1::+1:

- ドメインルールを厳格にしたあとに、そのルールに違反しているかどうかを記録する「検出によるアプローチ」は良さそうだと感じた。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010519595146285127)
- 一方で記録するだけしておいて、データの質を変えられないから何も進まないパターンは起きそうなので、どのようにリファクタリングをしていく計画を立ててからじゃないと辛そう:+1::+1:
- 本書にも書いてあるとおり、新しいAPIに作り直すというアプローチとセットにするのが、良さそう

- 後からドメインプリミティブを導入するときに既存データの問題が常に立ちはだかっていたけど、『検出によるアプローチ』で本当にデータが問題ないかチェックするというのは非常によい発想だと思った。これは応用できそう。
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010515774064050266)
- 動的型付け言語だと IDE のサポートがどうしても薄めになりがちで困っていたが、それを検出によるアプローチで良い感じにカバー出来たりしないかな？ :+1::+1::+1:

## 疑問

---

# 12.3 ログにおける未検査の文字列
## 目安の時間
- 22分

## 感想・気づき

> p. 447 オブジェクトそのものをログに出力するのではなく、出力しなくてはならない情報のみを明示的にフィールドへアクセス・メソッドを使って指定することです:+1::+1:

- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010522750848340028)
- toString() でクラスの情報を全部出さないようにするという意味だと受け取った

## 疑問

---

# 12.4 過保護な実装
## 目安の時間
- 22分

## 感想・気づき

> p.451 実際、応急処置として単純にif文での検査をしているだけに過ぎません。

- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010530945310400602)
- 実際開発中に対応しようと思ったら、とりあえずでif文で済ませてしまいそう。そっちのが楽だからだけど、いつかは明示的な設計に切りかえようというタイミングが来るのかな。
- きっと来ないですね。

> p.451 加えて、今回のコードに含まれるもう1つの問題は、至る所に同じコードがコピーされている点です。

- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010525340327743568)
- よく、フロントエンドとドメイン層両方でチェックする是非とか、それぞれがどの観点でどこまで担保するの？の話だと思った。この辺りの合意をチームでできていない状態の結果を「コード自体に信頼をおかないコード」という節として話してるのも面白い。（まさに、他のチームのコードを信頼してない):+1::+1::+1:
- (一例なのは理解した上で) レイヤごとのチェックは別の関心事なので、同じチェックをしていても必ずしも問題であるとはかぎらないのではないか。
- ここでは「コードが別のコードを」信頼していない、つまり、同じレイヤ内であっても、責務が適切に定められておらず、ある値が正しいことを保証するようなコードになっていることに確証を得られない状態であることが問題ということ。たとえ自身のコードであっても問題であり、「チームが他のチーム (のコード)」を信頼できないというのは、深読みしすぎに感じた。

- `Optional` っていいよねー便利だよね～　くらいの感覚でいたが、本書で述べられているように if 文による null チェックを迂回・隠蔽しているだけのパターンになっている部分がありそうでドキっとした。 :+1::+1:
- [Discord](https://discord.com/channels/432531367427964929/911610565103845387/1010527795161616384)

- リスト 12.9 を見ると、データと処理をオブジェクトにまとめるというまさにオブジェクト指向という感じがするのですが、なぜ我々はリスト 12.8 みたいなコードばかりを書いてきたのか。

## 疑問

> P.453 `result = result && item.isbn().equals(isbn)`

- [Disord](https://discord.com/channels/432531367427964929/911610565103845387/1010523560009285732)
- result は最初 false なので、ずっと false なのでは？:+1::+1:

---

# ================= 9/3後半はこちらから ===================

# 12.5 DRY(Don't Repeat Yourself)原則の誤解
## 目安の時間
- 22分

## 感想・気づき

> p.457: この DRY 原則はよく誤解されており、この原則を知識や考え方に適用させ るのではなく、テキスト としてのコードに適用されるものとして解釈されている傾向があり ます。
- ここ重要。これは本当に多い誤解なので、本来の意味で言っているのか、誤解された意味で言っているのか、話すときに注意したいポイント。:+1::+1::+1:
- Don't Repeat Your Concept とかなら良かったのになぁ...
- DRY原則はコードの重複を排除する的な意味で勘違いされやすいけど、IDEの機能が発達したことが拍車掛けているっていう指摘は確かになぁと思った。:+1:

> P.457 依存地獄（dependency hell）
- この用語を積極的に使っていきたい。:+1::+1:

- > p.459 TIP：名前に「Util」と付いたクラスはドメイン・ロジックに関するちょっとしたヘルパー・メソッドを集めたものとして便利かも知れませんが、それを完成形とすべきではありません。このような処置はさらなるリファクタリングを見据えた一時的な処置として認識すべきです
- utilとかcommonという名前になる時点で異なる概念を纏めてようとしていると見るべきなのかもしれないと感じた:+1::+1:
- 全然違う話ですがCommonUtilクラスがおります。
- > p.459 このことは、「もし、注文番号のフォーマットを変えたら、それに伴い、郵便番号も変えなくてはならないのか？」と言うことを考えてみれば明らかに判断できることでしょう。
- 重複を見つけたときに、同じ知識の表現なのかなかなか判断できないなと思っていたが、こう考えれば良かったのかと思った。同じ判定とか同じ処理とかこの方法で考え直してみたい。:+1::+1:

## 疑問

- 偽陰性のコードはパッと見た時にわからない問題。ドメイン・プリミティブを導入すれば簡単って言っているが、従来のコードはそのまま残ってしまうんじゃないか？って思うけどどうなんだろう。
- 一貫したチェックが行えるようになるから、それで目的は達成できるってことだろうか:+1:

---

# 12.6 ドメイン固有の型における不十分な妥当性確認(validation)
## 目安の時間
- 22分

## 感想・気づき

## 疑問

- ビジネス・ドメインの観点に置いて、個数などの厳格な定義がない場合はどう妥当性を担保すればよいだろう？:+1::+1:
- その場でドメインエキスパートと決める？
- それとも妥当そうな値をチームで決める？
- 既にある業務を効率化する目的のソフトウェアなら、ドメインエキスパートに聞けばわかりそうだけど、自らサービスを作っていくところはチーム全体で決めそうな感じがあるなぁ
- 定義がないなら、任意の自然な値を扱えるようにするか、定義することを検討するか。業務に携っている人たちの間で暗黙知として存在するかもしれないので、確認した上で決めるべき。ただし、尋ねたら、xxx個くらいでいいよ、って何も考えずに安易に回答されるケースもあるので、注意も必要。

---

# 12.7 テストだけで十分なのか？
## 目安の時間
- 22分

## 感想・気づき

- > p.464 テストを作成する際、開発者は記述したコードが意図したように振る舞うのか、そして、バグが忍び込むことを防ぐセーフティ・ネットがきちんと構築できているのか、という2つのことを主に考える傾向があります。
- 自分は前者のところを重視して作成する事が多い。後者の方は最低限、異常値の数パターンくらいなので、あまり出来ているとは言えない:+1:
- 後者が出来ているテストコード殆ど見たことがないなあ

## 疑問

- `string` の引数に長大な文字列を入れるようなテストは、本にもあるようにログやDBなどシステム外の影響も受けるためユニットテスト単体だとカバーしきれないパターンもありそう。どのようにテストするのが良いだろう？:+1:
- P.296 には `repeat("X", 40000000)`みたいなコードがありますね。

---

# 12.8 不完全なドメイン・プリミティブ
## 目安の時間
- 22分

## 感想・気づき

- > p.466 ドメイン・プリミティブを設計する際、ドメイン・プリミティブはできるだけ小さくなるように設計するのが好ましく、場合によっては、対象となる値をそのドメインの用語を名前に持ったクラスに抱えるだけで十分なこともあります。
- あまりDDDの方を学習できてなかったからかもしれないが、値を持つだけでもいいというのは意外だった。小さいクラスばかりになりそうだと作るの控えめになってしまうところがあったが、もう少し積極的に使ってみたいと思った。:+1::+1::+1:

- ドメインプリミティブを型安全にするためだけに使うと不完全になりがちだなあと思った。HogeId 型みたいなものもそれはそれで役に立つが、粗製濫造すると不完全なものが混じってしまいそうなので注意したい。:+1::+1:

> p.467: 金額には double を使わない
- p.467にあるコラムの中で、セントだけで表現する方法はなるほどなって思った。やり方はシンプルだし、表現をする時だけ気をつければいい方法だなと感じる:+1:
- 端数の切り上げ／切り捨てもいくつかの流儀があったりするので、そういう点でも、基本型をそのまま使わずに表現して、演算も定義してやるのがいい (そういうライブラリに頼りたい)

> p.466 完結した概念を完全に捉えきれていないときです
> p.469 通常、必要な概念が明示的に表現されずに暗黙的に理解されていることで起こる問題は、暗黙的に捉えていた概念が急に明示的に必要とされるようになったときに認識されます。
- 最初から捉えることが出来れば良いけど、暗黙的になっている概念に気づくのは難しいと思う。全てのドメイン・プリミティブは不完全かもしれない。ぐらいに思って常日頃疑っておかないといけなそう
- p.470のTIPにもあるとおり、通貨の情報を別から取らなければいけない状況になったときに、怪しいと感じてドメインプリミティブが変更されるとは思うので、そういうフィードバックには敏感になるべき
- p.435で「まとめられた概念のなかから間違った概念を取り除くのはかなりの負担が伴うことがある」と書いてあったので、クラスにまとめすぎていた場合は気づけても再設計キツいのかな～:+1::+1:
- 持っているプロパティが3〜4つ以上出てくると個人的には「なんか不必要なものが混ざっていないか？」という設計を考えるチャンスだと思っている

- ドメインプリミティブ（あるいは値オブジェクト）を使う時、計算が必要になったら毎回計算メソッドを実装するの？　的な事を皮肉交じりで言われることがあるのだけど、今回の通貨や金額の例のように必要なら実装するのがやはり安全でよい。:+1::+1:
- そんなに加算乗除が必要になるパターンはないと思うので尚更。

## 疑問

---