マイクロサービスアーキテクチャの5章は、モノリスをどうやって分割していくかが焦点です。サービス間での依存関係をできるだけ断つために、共有データや共有テーブルを避け、分割していくやり方が書かれています。
モデリングの観点からは、記述が不足なところがあって、現場のモデルに照らし合わせて考えることが難しいので、これをもう少し掘り下げて考えてみます。
データモデリングの手法としては、拙作のイミュータブルデータモデルが前提となりますので、未見の方はそちらをまずご参照ください。
エンティティは、リソース系とイベント系の2種類に大別するので、これらの関連の種類で言うと、R-R, E-R, E-Eの3つあります。これを順に分割するとどうなるかを考えます。
これらの呼び方はTM手法に準じます。
http://tmdmaker.osdn.jp/doc/ch08.html
リソース-リソース(R-R)
強い依存関係
リソース間に強い依存関係、「子は親が無ければ存在しえない」があれば、そこで分割するのはやめたほうがよいでしょう。
上の例では、ホテルと部屋の関係において、部屋はホテルが無いと存在しえないので、部屋だけサービス化されることはまずないでしょう。この間での分割は運用の面倒さしか産まないと思われます。
弱い依存関係(コンポジットの関係)
次に、リソース同士が独立して存在し得る関係性は分割の対象になりうるかもしれません。
この場合、リソース間に対照表を置きます。
例えばパーツショップが、BTOパソコンも販売するような業務をシステム化するときに、パーツ管理業務とBTOパソコン組み立て業務で、別々の組織構成でマイクロサービス化したいことが出てくるかもしれません。
このとき対照表である"パーツ構成"は、どちらのサービスに配置すべきでしょうか? これはパソコンサービス側に配置しておけば良さそうです。
- パソコンを組み立てるときには、パソコンサービスに問い合わせてパーツ構成を取得し、パーツサービスに問い合わせて、それらの詳細や在庫をまとめて取得する。
- パーツからどのパソコンで使われているかを問い合わせるニーズは、「レポート」の用途でしかなさそう。
似たような関係性には、沿線-駅やエリア-都道府県などがあります。
弱い依存関係(コンポジット関係ではない)
じゃらんや楽天トラベルをみると、ユーザが宿をお気に入りに登録(クリップ)する機能があります。
顧客と宿は完全に独立して存在しえて、どちらかがどちらかの構成要素になるというコンポジット関係も無いので対等です。この場合、それらの関連を示す「お気に入り」というのはどう扱えばよいのでしょうか?
これは一概に正解の形を作るのは難しそうです。この例で顧客と宿がそれぞれ、顧客サービスと宿サービスに分割されているとすると、お気に入りの持ち主は"顧客"なので、顧客サービスにもたせるのが良さそうです。
宿サービス側からお気に入りにアクセスしたい用途としては、
- お気に入りに多く登録されている宿のランキングを出す。
- お気に入りに登録されている数と予約アクションの数を比較し、コンバージョンが低い宿への改善提案をする。
あたりが考えられますが、これは"5.13 レポート"として取り扱えば良さそうです。
また、この「お気に入り」はそうなりにくい気がしますが、これが「リコメンド(おすすめの宿)」のような境界付けられたコンテキストとして認識される場合は、独立したサービスになることもあるでしょう。
イベント-リソース (E-R)
リソースが複数のイベントから参照される場合、共有することはできないので、リソースエンティティはどのサービスに持つかを決めなくてはなりません。
リソースが静的(システム内で更新されることがほとんどない)
このケースでのリソースの持ち方は、"5.8 例:共有静的データ"に分かりやすく書いています。
- 各サービスに重複してリソースエンティティをもちテーブルとして実装する。
- 各サービスに重複してリソースエンティティをもち、プロパティファイルやEnumなどで実装しコードベースに入れる。
- リソースエンティティを独立したサービスとする
あまり更新されないんだから重複してもつのは、十分現実的な解かと思います。
リソースが動的(ガツガツ更新される)
これが一番難しいケースだと思います。キレイな形は取りづらく、リソースエンティティを境界付けられたコンテキストとして認識し、独立したサービスとして扱うことがそこそこ納得のいく落とし所になるかと思います。
"5.9 例:共有データ"の、倉庫と経理が顧客レコードに読み書きしているところから顧客サービスを切り出すのは、その代表的な例ですが、現実にはこんなのもサービスとして切り出さなきゃいけないの? というところが出てきやすい悩みどころになるでしょう。
静的・動的の判断基準も難しく、ある程度の試行錯誤は辞さない設計判断が必要になるでしょう。
イベント-イベント (E-E)
イベント間の分割は、マイクロサービスサービス分割の主役です。イベントエンティティのまわりに業務の塊ができるので、業務の分割 = イベントエンティティの分割になります。
イベント間の関連は次のように、時系列で早い方のIDを遅い方のエンティティの外部キーとして作られます。
これをサービスに分割する場合は、"5.7 例:外部キー関係の削除"をするだけです。
イベント間にn:1の関係があれば、対応表を間に置きます。
この例の分割は、対応表を時系列の遅い方のエンティティが含まれるサービス側に持ってくるのが自然です。
ただし、イベントエンティティは「××ステータス」のような属性をもち、複数の種類のイベントを包含したモンスターエンティティになっていることが、実際の現場では多いので、これをイミュータブルに設計し直すことがまず必要です。
