【メモ】【Firebase】自分宛のFirebaseについてのメモ
はじめに
Firebaseを触っているが、Firebaseとアプリケーション、Google Cloudとの関係がいまいち理解できていなかったので、公式のドキュメントを読みながらメモを残していく。
Firebase プロジェクト、アプリ、プロダクトの関係
以下、公式ドキュメントのFirebaseプロジェクトの説明。
Firebase プロジェクトは Firebase の最上位のエンティティです。プロジェクトでは、Apple アプリ、Android アプリ、ウェブアプリを登録できます。Firebase にアプリを登録すると、アナリティクス、Cloud Firestore、Performance Monitoring、Remote Config などの Firebase プロダクト用の Firebase SDK をいくつでも追加できます。
もう少し読み進めると、Firebaseのプロジェクト階層は以下のように定義されていると書かれている。 - Firebaseプロジェクトには1つ以上のアプリを登録できる。 - Firebaseプロジェクトは、すべてのアプリと、そのプロジェクトようにプロビジョニングされたリソースとサービスを格納したコンテナのようなものとなっている。 - 同じFirebaseプロジェクトに登録されているすべてのFirebaseアプリ同士はFirebaseプロジェクトのリソースを共有する。
FirebaseプロジェクトとGoogle Cloudの関係について
Firebaseプロジェクトは、Firebase固有の構成とサービスが有効になっている Google Cloudプロジェクトとなっている。
実際にFirebaseプロジェクトを作成した後、対応するGoogle Cloudコンソールのプロジェクトのラベルページに飛んでみると以下のように「firebase」という名前のラベルの値がenabledになっていることが分かる（=Firebase固有の構成とサービスが有効になっている ）。
【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅳ部 第14章（続き）
【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅳ部 第13章
はじめに
前回の続き
第Ⅳ部
第13章 コンポーネントの凝集性
コンポーネント凝集性には以下の原則がある。
- 再利用・リリース等価の原則（REP）
→再利用の単位とリリースの単位は等価になる
→一つのコンポーネントを形成するクラスやモジュールは同じタイミングでまとめてリリース可能でなければならない
- 閉鎖性共通の原則（CCP）
→同じタイミング、同じ理由で変更されるものはひとまとめにする
→そうでなければ、別々のものに分ける
→この原則は単一責任の原則（SRP）の定義をクラスからコンポーネント用に置き換えたもの
- 全再利用の原則（CRP）
→不要なものには依存しないこと
→この原則はインターフェース分離（ISP）の原則を一般化したもの
REP、CCP、CRPはプロジェクトの状況によってどこに比重を置くか都度検討する必要がある。
以上。
【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅳ部 第12章
はじめに
前回の続き
【メモ】【読書】Clean Architecture 達人に学ぶソフトウェアの構造と設計 第Ⅲ部 第11章 - ふじもりの忘備録
第Ⅳ部
第12章 コンポーネント
コンポーネント →デプロイの単位を指す
12章はコンポーネント登場の歴史についての解説だった。 取り立ててこの章でメモしておくことはあまりないかな...
以上。
