O’REILLY Learning「ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析」5章〜6章
https://learning.oreilly.com/library/view/-/9784814400065/
5章 コンポーネントベース分解パターン
コンポーネントベース分解パターン
コードベースの構造化と名前空間（またはディレクトリ）によるグループ化がある程度されている場合に、モノリシックアプリケーションをとても効果的に分解できる手法。
コンポーネントの特定およびサイズ調整（Identify and Size Components）パターン
ドメイン共通コンポーネントの収集（Gather Common Domain Components）パターン
コンポーネントのフラット化（Flatten Components）パターン
コンポーネントの依存関係判断（Determine Component Dependencies）パターン
コンポーネントドメインの作成（Create Component Domains）パターン
ドメインサービスの作成パターン
モノリシックアプリケーションから分散アーキテクチャへの移行を検討する際によく聞かれる質問に、次の3つがある。
・既存のモノリシックアプリケーションは分解可能か？
・移行にかかる全体的な労力は大まかにどれくらいか？
・必要になるのはコードの書き直しか、それともリファクタリングか？
6章 業務データの分解
一般的に、データは企業にとって最も重要な資産だ。
データを分解したり再構築したりすると、ビジネスやアプリケーションに支障をきたすリスクが高くなる。
モノリシックアプリケーションを個別のデプロイメントユニットに分割するのと同様、モノリシックデータベースも分割するのが望ましい（あるいは必要な）場合がある。
データ分解要因（データを分解する根拠となる要因）
→変更制御／コネクション管理／スケーラビリティ／耐障害性／アーキテクチャ量子／データベース種別の最適化
データ統合要因（データを統合する根拠となる要因）
→データ関係／データトランザクション
破壊的変更
境界づけられたコンテキスト
「5段階プロセス」と呼ばれる手法：データを分解する際に特に効果的な方法
ステップ1：データベースを分析し、データドメインを特定する
ステップ2：テーブルをデータドメインに割り当てる
ステップ3：データベースコネクションをデータドメインごとに分離する
ステップ4：スキーマを別個のデータベースサーバーに移動する
ステップ5：個別のデータベースサーバーへコネクション先を切り替える
データベース種別を選択
・評価項目
・学習曲線
・データモデリングのしやすさ
・スケーラビリティ／スループット
・可用性／分断耐性
・整合性
・プログラミング言語のサポート、プロダクトの成熟度、SQLのサポート、およびコミュニティ
・読み込み／書き込みの優先順位
↓
評価されているデータベース
・リレーショナルデータベース（RDBMS）
・キーバリューデータベース
・ドキュメントデータベース
・列指向データベース
・グラフデータベース
・NewSQLデータベース
・クラウドネイティブデータベース
・時系列データベース