Vol1：マイクロサービスの概要->https://qiita.com/get-latest-information/items/e959d12a54a378ffceb2
Vol2: DDD(ドメイン駆動設計)を用いいたマイクロソフトサービス設計アプローチ

##今回のフォーカス
MicrosoftのAzure Docsで色々な機能やアーキテクチャなどがまとまっているので、
今回は、マイクロサービス関連で下記ページをサマリーします。なるべく短い言葉を使って。
◆ドメイン分析を使用したマイクロサービスのモデル化
https://docs.microsoft.com/ja-jp/azure/architecture/microservices/model/domain-analysis

##ドメイン駆動設計(DDD)とは・・・

DDDは、MSなアプリを開発するためのフレームワークを提供。どのような順序でやればいいのかを教えてくれる。
DDDはすごい簡単に言えば、ビジネスの観点(技術ではなく)から高品質のソフトウェアを設計する手法。
＊DDDに関しては別途勉強予定。

##DDDのアプローチをドローン配送アプリに適用
以下の手順。今回は、下記の１と２のみ。３と４はVol3で。
全体の流れ：ドメイン分析→境界づけられたコンテキストを定義→Entity/Aggregates/Serviceを定義→マイクロサービスの識別

ドメイン分析
　-> ビジネス用ドメインを分析して、アプリの機能的な要件を理解。ドメインを分割して、コアドメイン、サブドメイン化する。
境界づけられたコンテキストを定義
　-> コンテキストはソリューション、１つのサービスのこと。ドメインに対して解決する機能を提供するもの。
　-> １コンテキスト=1アプリ(+1DB)
Entity/Aggregates/Serviceを定義：
　->コンテキスト内でEntity/Aggregates/Serviceを定義。
マイクロサービスの識別

#ドメイン分析
以下は、ドローン配送においてドメインを分析したもの。
ドメインの中で、コアドメイン、サブドメインに分けていく。
コアドメイン：Shipping(出荷)とDron Mgmt(ドローン管理)
サブドメイン：アカウント、Invoicing、コールセンター　→他の部分は何になるんだ？サブドメインじゃないのか？

##境界づけられたコンテキストを定義
簡単にいうと、機能をグループ化して、アプリケーションを開発する単位を分割すること。
各ドメイン間を結んでいる線は、コンテキスト同士がやりとりする場所。つまり、サービス同士が連携する。
＊ドメイン分析でのそれぞれのドメインの数と下記とでドメイン数が違う(LoyaltyやUserRatingがない)のは、グループ化されたからということでいいのかな。
＊なんでDrone Sharingが急にAccountsとやりとりするようになるのだろうか。アカウントに紐づくのは理解できるが。

##感想
流れはなんとなく理解できるが、正直難しくてよくわからない。
実際にDDDの進め方をためしているものがGithubに上がっていたりするので、挑戦してみようかなと。