関係ないけど書籍リファクタリングといい、前半で背景や概要を説明しつつ後半で挙げられるたくさんの具体例に対するリンクを貼っていくスタイルの執筆が好きそう

• パフォーマンスを測定する指標

  • レスポンスタイム
    • Request -> responseまでの時間
  • Responsiveness
    • UIで何かアクションを実行したあと、反応が来るまでの時間（ローディング画面が出るとか）
  • Throughput
    • 一定の時間にどれだけの処理を行えるか(transactions per second
  • Latency
    • 物理的にどれだけ情報の伝達に時間がかかるか
  • Load
    • システムにどれだけの負荷がかかっているか。同時接続人数とか
  • Load sensitivity
    • どれだけloadによってresponse timeが変わるか
  • Capacity
    • 最大throughput、或いは許容可能なthroughputまで低下するloadの指標
  • Efficiency
    • resourceあたりのthroughputを指標化したもの
  • Scalability
    • ハードウェアを追加したときにどれだけパフォーマンスに影響を与えられるか
    • スケーラビリティに振った方が、capacityやthroughputを高めるより良いのではないか

• パターンが解決したい問題を理解しておくことが大切

  • 知識に索引をつけておく（よく言われるやつ、この本からきてた）

• my test for this book is not whether it's complete but merely if it's useful

  • 自分がやっている事のtestは何か？って面白い考え方

レイヤー化

• 自分が思うメリット
  • 下の層を他の層が使いまわせる
    • tcp/ipとかめちゃくちゃ色んなものに使いまわされている
    • 電話線も例として挙げられるかも
  • 層を独立して開発できる（IFさえ決めておけば）
  • 変更時に確認範囲が狭まる（ドライバを付け替えたからといってOSコマンドが変わるわけではない）
• PoEAAのメリット
  • 他の層について知らなくても特定の層について学べる
    • アプリケーション層を編集するときに使っているDBの種類までは意識しなくても良いイメージかな
    • この辺りがDBトリガーの不味い点と言えそう（インフラ層まで調べないとアプリケーション層に関する学習が完結しない）
  • 同じ層であれば他のコードと入れ替えられる
    • Repositoryパターンを使っておけばレポジトリ自体は種類を問わないイメージ？
  • （層を跨いだ参照を許さない厳格なレイヤー化の場合）変更の影響が及ぶ層を限定できる
    • RepositoryのIFが変わってもドメイン層が影響を受けることはない、的な
    • ethernetの仕様が変わってもftpまで変更は及ばない（tcpで止まる）的な
  • 標準化しやすい
    • レイヤーに責務が混ざっていると「これって何の標準なの？」って確かに揉めそう
      • w3cとか見てると「君らどこまでの標準化を担当してるの？」って気になる（故にwhatwgが誕生した経緯もありそう）
      • 最近もうちょい足並み揃えようよって合意したらしい
• デメリット
  • 全ての変更を特定の層に隠蔽できるわけではない（新しいフィールドをui、dbの両方に追加しなければいけないとか）
  • パフォーマンス上のデメリット

レイヤーの歴史

• client-serverが走り
  • vb,delphyあたりはクライアントツールとしてsqlと密結合したuiを提供していた
  • しかしドメインロジックが増えてくるとそれをuiに記述する（コードの重複が増える）或いはdbのプロシージャ化（表現が限定的、移植が困難）する必要に迫られた
• そこでooの文化から三層アーキテクチャが誕生
  • ui,domain,data
  • しかし当時のアプリケーションの単純性から一気にはやることはなかった（client-serverで事足りる）
  • webの登場で事情が変わった。uiにロジックを書いていると、webブラウザで実行できるバージョンを作ろうと思ったら大幅に書き直す必要が生じる
  • emojiの流行でutf8が普及した感じに似てる
    • 今のアプリケーションをalexaに全部移植するとしたらどれぐらい工数かかる？って問いかけると良いのかもしれない
• downloadable appletを通して一部の処理をクライアントに寄せることで高速化も可能
  • ブラウザ搭載のJVMあったの知らんかった

organizing domain

Table module

• テーブルやviewの行からドメインオブジェクトへの変換を全て担うインスタンスを作るパターン
• ドメインモデルとRDBの変換は難易度が高くなりがちなのでそこを担う（Repositoryと考えて差し支えないんだろうか）

Service Layer

何を書くか

• トランザクションラッパーやセキュリティ上のチェックを行うのが妥当
  • DDD+onion的な観点のアプリケーション層とは少し違うかも（onionだとアプリはinfra agnosticに作るから）
• ユースケース単位のドメインロジックもここに書く
  • 複数ユースケースから参照されるようになったらエンティティに移すとな
  • でも正しく使われるの難しそう（本当にロジックが重複しているか確認するの辛いよね）

気になったポイント

• presentationとdata sourceは非対称（全く同じものとは言えない）のは何故か
  • presentationはクライアントを問わず同じ挙動を示すべき
  • data sourceはクライアントによっては挙動が異なる可能性がある
    • 例えばバッチ処理とか管理画面からの操作を毎回ドメインロジック通してたら不都合が生じる可能性があるので、クライアントに依存すると言える
• なんでブラウザjvmは負けたんだろう
  • 脆弱性が多かったと書いてあった
• MVCのモデルってdomainとdatasourceの責務が重複してそう
  • これが色んな負債のもとになってるケースをよく見るけどもうちょい細かく分解したいと当時は思われなかったのだろうか？

RDB

• ISAMはMyISAMと同じかな
  • トランザクションも外部キー制約もない時代
• VSAMは言語に密結合している。RDB自体が疎結合になってきたのもSQLの功績と言える

• SQLは結構ベンダー独自の進化が激しい