学習した事をノート代わりにまとめていきます。
主に自分の学習の流れを振り返りで残す形なので色々、省いてます。
Webエンジニアの諸先輩方からアドバイスやご指摘を頂けたらありがたいです！

第19章方針とレベル

最初に書かれていることは今までやった事のまとめに近い内容である。
コンピュータプログラムは、入力を出力に変換をどのように行うかの方針を決めたもの。

アーキテクチャの技芸ではまとめたコンポーネントを上位の物から下位の物にと有向非循環グラフにすることがよくある。この様にするのがアーキテクチャの仕事

優れたアーキテクチャではこうした依存性の方向は接続するコンポーネントのレベルで用の様な設計にするのかを決める。どの様な場合でも、下位レベルのコンポーネントが上位レベルのコンポーネントに依存する様にしっかりと設計する必要がある。

レベル

レベルによって上位と下位を決めている。
「入力と出力からの距離」から離れていれば上位に、近ければ下位になる。

この場合、入力と出力からもっとも離れているコンポーネントはTranslate(変換)になる。
これがシステム上最上位のコンポーネントになる。

ここで重要なのがソースコードの依存性はデータフローから切り離しレベルで結び付けるべきであるという事。

encrypt()は良くない、上位が下位の物に依存しているからだ


function encrypt()
 while(true)
  writeChar(translate(readChar()));

図19-2のEncryptは自分の処理を変える必要がない、これはソースコードの依存性を上位レベルの方針に向けているからである

データの処理の仕方をエンティティと呼ぶ。

これはプレイベートで内部的なプロパティ

-principle
-rate
-period

Publicなmethod

-principle
-rate
-period

Railsはmethodにビジネスロジックを書く
Plain Old Ruby Object

ここで重要なポイント
エンティティなどは上位レベルとして定義される（ビジネスロジックは遠い物になるので）、この場合はユースケースなどは下位になる様に設計すべきである。

リクエストとレスポンスのモデル
ユースケースなどがSQLやHTMLに直接干渉してはいけない。

最初の例で言っているのは建築士なら設計図を見たら作ろうとしているものが何であるかわかる、つまりエンジニアもアーキテクチャを見ればこれが何であるかを理解することができるという事を言いたい。

日本ではあまりなじみの無い例えをここの章ではされている。アメリカの１戸建ての家では普通うのダインングルームの別にお客様用のダイニングスペースがあるこれがダイネットエリアのことである。

だがウェブはどうか？

　例として2020年の東京オリンピックのチケット販売のページで大量の人からのリクエストをさばかないといけないので待ち行列にしている点もエンジニアとしたらどうかと考える人も多いだろうが、ビジネスロジックとしては優れたものと言える。
フレームワークはツールであり、生き方ではない

ここで言いたいのはRailsにおける初めはRailsのレールに100%従う方針で問題無いがRailsのレールを乗りこなせる様になることができればケースによって自分でどの様にレールを外れてフレームワークを活用するか考えることが大事であるという事を言っている。
テスト可能なアーキテクチャ

　しっかりとクリーンアーキテクチャでこれまで述べてきた通りにエンティティやユースケースなどは分離されており、依存関係がしっかり設計されているのでユニット単位でしっかりとテストができている状態である、逆にできなければ設計が間違えているという事だ。
まとめ

　Railsにおいてmodelがしっかり書かれておりそのビジネスロジックを見ればどういうものが分かる。

しかし最後の「それは詳細だから、まだ気にする必要はないよ。あとから決めよう」という部分は全てをあとから設計するのは難しい点がある。