スキップしてメイン コンテンツに移動

マイクロサービスのアーキテクチャー研修メモ

マイクロサービスのアーキテクチャーに関する研修を受講したので、ただの箇条書きだがメモとして残しておく。

* SOAとMSAは考えとしては近しい。
* ただし、SOAでは思想として、中央集権的な部分がある。
* サービスとして切り出すところまでは同じだとしても、そのサービスやデータ管理においては最終的に統合することが前提になっている。
* マイクロサービスの適切な単位・粒度、というのはまだ確立されていない。
* マイクロサービスとAPIは関係性としては、マイクロサービス>API。マイクロサービス単位にAPIが1単位になっているわけではないが、少なくともAPIはマイクロサービスの範囲内の物事を扱うもので、そのI/Fとしての表現。
* サービスやAPIを識別するアプローチとしては、ユースケースからAPIの識別を、ドメイン分析からサービスの識別を、データモデル分析からデータのマッピングをする、といった関係性のイメージ。

この話は結構聞いていると考えがクリアになってきて、また、一口にこれが最適と言える単位・粒度が確立されていないというのも、巷でなかなか明確な回答を探しても見つからないことの裏打ちになって、自分なりの考えを確立するための努力をしても良いなあと思えるだけの機会にはなった。

マイクロサービスの話の文脈ではドメイン駆動設計の話もよく出てくる。
『実践ドメイン駆動設計』も近頃どうにか読み終えたばかりなので、最後の方に載っている所謂軽量DDDを成すような技術的な設計パターンが自分にはやはりわかりがいいなあと思いながら、ドメイン設計の話も徐々に読み解している。

ドメイン分析では次のように触れられていたので、チーミングの時や、モデリング活動の時には忘れないようにしたい。

よくあるのが、そのドメインについての経験がない「ドメインエキスパート」が複数集まったときに、単なるビジネスアナリストとして動いてしまうということだ。

出典:実践ドメイン駆動設計 P.8

 

業務のエキスパートのメンタルモデルを反映したソフトウェアを開発する。これは決して、「現実世界」をそのままモデリングするということではない。DDD では、現状をそのままモデリングするのではなく、業務により役立つモデルを作る。

出典:実践ドメイン駆動設計 P.9