【CleanArchitecture】読書メモ2

第4章 構造化プログラミング

機能分割がベストプラクティス

第5章 オブジェクト指向プログラミング

• OO言語が安全で便利なポリモーフィズムを提供しているというのは、ソースコードの依存関係は（例えどこにあっても）逆転できることを意味する
• システムにあるモジュールを個別にデプロイできるなら、別々のチームが個別に開発できる。これが独立開発可能性である。
• OOとは「ポリモーフィズムを利用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」

第6章 関数型プログラミング

• 関数型言語の変数は変化しない
• アーキテクトは変数の可変性に配慮すべき。
• 競合状態、デッドロック状態、並行更新の問題の原因が全て可変変数にあるから。
• 不変に関する最も一般的な妥協となるのは、アプリケーションまたはアプリケーションのサービスを「可変コンポーネント」と「不変コンポーネント」に分離すること。
  • 不変コンポーネントにだけ変数の状態の変更を許可する。
  • 状態の変更により、これらのコンポーネントは並行
    • 変更可能な変数を並行更新や競合状態から保護するために、トランザクショナルメモリを使用するのが一般的
    • トランザクショナルメモリとは、データベースがディスクのレコードを扱うのと同じように、メモリ内の変数を扱うもの。

イベントソーシング

イベントソーシングの背景にある考え方

• 顧客の口座残高を保持する銀行アプリケーションがあるとする
• 入出金の取引を実行すると、口座の残高が変更される
• 口座の残高を保存する代わりに、取引のみを保存rjらでもMTGできます考えてみる。残高を知りたい場合は、これまでのすべての取引を合計する。この仕組みであれば可変変数は必要ない。
• このアプローチは時間が経つにつれて、取引の数は際限なく増加し、合計を計算するために必要な処理能力が維持できなくなる。この仕組みを永遠に機能させるには、無限のストレージと無限の処理能力が必要。
• しかしこの仕組みを永遠に機能させる必要はなく、アプリケーションの寿命期間だけこの仕組みを機能させるなら既に十分な記憶容量と銃l￥分な処理能力を持っている。
• イベントソーシングは状態ではなく取引（トランザクション)を保存するという戦略。
• データストアに対して、削除や更新は行われない。その結果アプリケーションはCRUDにはならず、CRだけになる。また、並行更新の問題も発生しない。
• 十分な記憶容量と十分な処理能力があれば、アプリケーションを完全不変にできる。したがって、完全に関数型になる。