ソフトウェア設計の結合バランス 読書メモ

gistfile1.txt

## 第一章

### メモ

- 1.2.2
  - ひさびさに正しいRepository Patternを見た気がする
    - これは間違ったRepository Patternを実装してる人が多い世に対する皮肉なのでは
- 境界
  - システム設計とは、本質的に境界（何が含まれ、何が含まれない、何が横断し、何が移動するか）とトレードオフに関するものであり、それは内部を形作るのと同じように、外部をも再構成する
- 相互作用
  - コンポーネントをどのように結合するかの設計が、システム設計の本質的な部分となる
- 過去に「依存の境界を見極める」という記事で、以下のようなことを書いたけど、同じこと言ってない？？？？？先見性があるのでは？？？？
  - 「依存しあう機能（ファンクション、メソッド、モジュール、API）の教会はどこになるのか、何になるのか」をよく意識している
  - 依存の境界をどう扱うか決めることが設計である
- この本にならって「依存」を「結合」に言い直してもいいね
- 上記記事のまとめ文

```
何が言いたいのかというと、

- 基本的に、機能間の依存を増やすとシステムは複雑になる
- 機能間の依存は少ない方が望ましい [^1]
- しかし、依存は必ず発生する
- 依存が発生する場合、機能間の依存の境界はどこにあるのか把握しておくことが重要

ということです。そして僕は、 

- 依存の境界をどう扱うか決めることが設計である
- 依存の境界を把握できてて、あとで分ける余地がある場合、よい設計につながる

と思っています。
```

- 一方で、「機能間の依存は少ない方が望ましい」とは書いたが、1章を読んで果たして正なのかと思ったので、続きを読んでいきたい
- しかしこの本がさして必要が無さそうな人が「わかる〜」って言いながら読む本で、本当に必要そうな人が手に取らなそうな雰囲気をひしひしと感じる


### 演習問題

- 1. b
- 2. c
- 3. d

## 第二章

### メモ

- ソフトウェア設計の複雑性
  - 複雑な状態とは
    - 全体（システム）はコンポーネントから構成されているにもかかわらず、個々のコンポーネントの機能についてははっきりと捉えられない
    - コンポーネントの動作を理解するには、すべての「パズルのピース」をつなぎ合わせ、結果として得られるシステムの動作を確認する必要がある
    - 「全部読まないとわからん」ってやつ
- 複雑性は主観
  - わかる。複雑と言いつつ、別の人から見るとそうでもないこともある
    - 余談: なので、こういう表現はなるべくしない。読みやすい、読みにくい、綺麗、汚い、もそう
  - そのため、複雑さの尺度としてクネビンフレームワークが提案される
- クネビンフレームワーク
  - 例が死ぬほどわかりやすい
- 複雑とは
  - 原因と結果の関係が緩やかに結びついている不確実性の高い状況
  - 結果が予測できないことから、複雑系における潜在的な原因と結果の関係を明らかにする安全な実験が必要
  - 行動の結果を後からしか特定できない領域（やってみないとわからない）を指す
  
### 演習問題

1. b
2. d -> c
3. a -> b
  - えー結果をコントロールできるわけだから明確系じゃないの？
4. d -> b
  - 関係があるのは複雑系まで
  - 関係が存在しない前提なのは混沌系
5. c

## 第三章

### メモ

- 本質的な複雑性と、偶有的な複雑性
  - 本質的: ビジネスドメイン固有のもの
    - 排除することはできない
  - 偶有的: 最適でない設計上の決定が生み出す副産物
- 線形な相互作用
  - 線形性: 変化の度合いが一定である
  - ちとピンとこない
    - 「意図しない結果」は線形性なシステムでも起こるのでは？
    - 確かに歯車はひとつ外すと動かなくなることが明確だから、複雑系ではない
- 大域的複雑性、局所的複雑性
  - モノリシックにすれば一般的に大域的複雑性は最適化するが、内部コンポーネントの局所的複雑性は解決しない
  - マイクロサービスにすれば一般的に局所的複雑性は最適化するが、大域的複雑性は増し、追加の偶有的な複雑性が増す
- 自由度
  - 最も単純なシステムは、自由度を持たない
  - システムを変更する際に考慮しなければならない自由度が多いほど、起こりうる相互作用の一部を見逃しやすくなり、意図しない結果を引き起こす複雑な相互作用につながる可能性が高くなる
  - 明確系と煩雑系には制約が存在する
  - 複雑系には制約が少ない
  - 混沌系には制約が存在しない
  - 過度に柔軟な入力によって、意図しない振る舞いを許して無いだろうか？

### 演習問題

1. d -> c
2. a -> d
3. b
4. c
5. d

## 第四章

### メモ

- モジュール（自己完結型のユニット）
  - モジュールは相互作用によって動くものを指さない？
- コンポーネントとモジュールの違いとは？
  - コンポーネントは協調するもの
- モジュール化設計とは、従来のシステムよりも広範な目標に対応することを前提としている
  - その目標は、現時点では未知であるが、将来必要必要な目標に対応することを目的としている
  - EnumerableとかForwardableとか
- モジュールはコンポーネントであるが、全てのコンポーネントがモジュールであるとは限らない
- シンプルであるということはモジュール性を取得している？
- 独立してコンパイルできる
- 明確に定義された機能を包含する境界であり、システムの他の部分から使用されるために公開されるものを指す
  - API?
- 抽象としてのモジュール
  - 抽象化が機能するには、具体的なケースには関連しつつも、全てに共通しているわけではない要素を排除しなければならない
  - その代わりに、複数のものを等しく適切に表現するために、グループの全てのメンバーに共有される側面に焦点をあてる必要がある
  - 抽象が余分な詳細を含んでいると、必要以上の知識を公開することになる
  - 妥当な自由度
  - railsはWebアプリケーションを抽象化したものなんだな
- 凝集の根底にあるのは結合
  - 凝集のことを良い結合と言ったりもする
  
### 演習問題

1. d
2. c
3. a
4. d
5. c