[勉強メモ]マイクロサービスを理解 Vol4

Vol1：マイクロサービスの概要->https://qiita.com/get-latest-information/items/e959d12a54a378ffceb2
Vol2: DDD(ドメイン駆動設計)を用いたマイクロソフトサービス設計アプローチ -> https://qiita.com/get-latest-information/items/5da2088e952c2562347f
Vol3: 戦術的DDDを使用したマイクロサービスの設計 ->https://qiita.com/get-latest-information/items/7d191527bbe7daac5cbe
Vol4: マイクロサービス境界の識別　＊今回

##今回のフォーカス
MicrosoftのAzure Docsで色々な機能やアーキテクチャなどがまとまっているので、
今回は、マイクロサービス関連で下記ページをサマリーします。なるべく短い言葉を使って。
◆マイクロサービス境界の識別
https://docs.microsoft.com/ja-jp/azure/architecture/microservices/model/microservice-boundaries

##ドメインモデルからマイクロサービスへ導くアプローチ

• アプリケーション内のマイクロサービスの識別
  1. マイクロサービスの機能が、複数のコンテキストに跨っていないことを確認。跨っている場合は、ドメイン分析の修正が必要。
  2. ドメインモデルの集約を確認。
     • 適切な集約は以下の特徴がある。
       1. 集約は、技術観点ではなく、ビジネス要件から派生している
       2. 集約には、高凝集度が必要。
       3. 集約同士は、疎結合である。
  3. ドメインサービスは、複数の集約に対するステートレスな操作。複数のマイクロサービスを含むワークフローである。
  4. 機能以外からの要件検討。機能以外とは、チームの規模、データの型、テクノロジー、スケーラビリティ、可用性、セキュリティなど。
• 上記の後は、次の基準で設計を検証
  1. 各マイクロサービスが１つの役割のみをもっていること。
  2. サービス間で頻繁な呼び出しが行われないこと。頻繁におこるなら１つにしたほうがいいかもしれない。
  3. 各マイクロサービスが、チームが対応できる規模であること。
  4. 他のサービスに依存してないこと。「Aをデプロイしないと、Bがデプロイできない」といったことがない、つまり個別に展開できること。

※１つのMSを複数に分割するほうが、複数のMSをリファクタリングするよりも簡単である。

##ドローン配送アプリにマイクロサービスを適用する
これまでの検討を踏まえたMS設計概要図↓

• 以下の要因に対しても考慮が必要。
  • ネットワークオーバーヘッドがあある。
  • データスキーマが適しているか。新たに作成する必要があるか。
  • レガシーシステムはあるか。
  • 他のコンテキストを担当するチームと簡単に連絡/連携できるか。

##感想
次の勉強候補。

• ソフトウェア開発関連 ->オブジェクト指向,クリーンアーキテクチャ,レイヤードアーキテクチャ,ヘキサゴナルアーキテクチャ
• アジャイル開発
• API