Contents
参考書籍
サム・ニューマン著，島田浩二訳 (2003) 『モノリスからマイクロサービスへ』，株式会社オライリー・ジャパン．
パターン1：共有データベース
概要：複数のサービスから同一のDBにアクセスする。
pros：実装が楽
cons：同一のDBに複数のサービスからアクセス＆管理するため、どの項目にどのタイミングで操作を行えば問題が発生しないかが不明瞭になる。すなわち、「サービスの結合」と「データの管理」の双方において大きな困難を抱えることになる。これは結果的にサービスのビジネス機能の凝縮度を高めることを困難にする。
備考：共有データベースは原則的にアンチパターンである。共有データベースがユースケースとなり得るのは①当該DBの中身が読み取り専用の静的参照データである場合②当該DBが読み取りかつ外部公開用のDBである場合（＝パターン4の公開DB）、である。
パターン２：データベースビュー（いわゆるビューテーブルの利用）
概要：元DBとは別に参照用のスキーマを作成し、外部システムや外部サービスのデータ参照先をそのスキーマに変更する。
pros：①情報隠蔽が可能（どの情報を共有・隠蔽するの制御が可能）である。②基礎となるDBに書き込まないサービスのオリジナルDBへのアクセスを回避できる（＝クエリがなくなる）ため、オリジナルDBのパフォーマンスが向上する。
cons：ない。あえて言えば、①ビューテーブル更新までデータが古い②一部のNoSQLではビューテーブルがサポートされているない③（ソーススキーマとビューを同時にデプロイする必要があるという意味で）デプロイ時結合が一つ増え、ひいては単一障害点リスクが増えるなど。
パターン３：データベースのサービスによるラップ
概要：元DBとは別に参照用のサービスを作成し、外部システムや外部サービスのデータ参照先をそのサービスに変更する。
pros：①情報隠蔽が可能（どの情報を共有・隠蔽するの制御が可能）である。②諸サービスのオリジナルDBへのアクセスを回避できる（＝クエリがなくなる）ため、オリジナルDBのパフォーマンスが向上する。
<ここまではビューテーブルと同じ>
その他のpros：①（ロジックをかませられるので）元DBの構造に依存しないビューを作成することができる②ラッピングサービスからDBへの書き込みも可能であるため、完全なラッピングも可能
パターン４：サービスのインターフェースとしてのデータベース（公開DB）
概要：「読み取り専用のエンドポイントとして公開するように設計された専用のデータベースを作成し、基礎となるデータベースのデータが変更されたときに、その変更を[マッピングエンジンを介して]読み取り専用のデータベース側に反映する（137頁）」
pros：①情報隠蔽が可能（どの情報を共有・隠蔽するの制御が可能）である。②諸サービスのオリジナルDBへのアクセスを回避できる（＝クエリがなくなる）ため、オリジナルDBのパフォーマンスが向上する。
<ここまではビューテーブルと同じ>
その他のpros：元DBとは異なる技術スタックでインターフェースのDBを作成することができる。
発展的なユースケース：DWHを用意して、そこを複数のサービスの参照先にする。
データの所有権の問題が発生する場合の対処
■パターン１：モノリス側でデータを集約したサービスインターフェースをエンドポイントとして公開する
こちらは主に、遠くにあるデータの管理権がモノリス側にある場合の対処法
■パターン２：データへのアクセスを新サービスに任せ、既存モノリスのアクセス先を元DBから新サービスに変更する
こちらは、遠くにあるデータの管理権が旧モノリスではなく新サービスにあるべき場合の対処法
新システムへのリプレイス時に、旧システムのDBと並行運用させつつスムーズに移行するための手法
■パターン１：アプリケーションでのデータ同期
- 旧システムを動作させたまま、旧DBと同期する新DBを用意する
- 新システムを旧DBメインで動作させ、新DBには書き込みのみを行う
- 新システムを新DBメインで動作させ、旧DBには書き込みのみを行う
- 旧DBを削除する
■パターン２：トレーサー書き込み
省略（※SoRが二つある事例で、今後の遭遇率が限りなく低いため）