はじめに
マイクロサービスアーキテクチャの開発を経験して感じたことを書き綴っています。
近年流行の兆しを見せているマイクロサービスアーキテクチャ。
DDDと相性が良いこともあってマイクロサービスアーキテクチャを採用している開発現場は非常に増えていると思います。
マイクロサービスの概要
マイクロサービスの最大の恩恵は機能単位でサービスを提供することで、メンテナンス性や可用性の向上が見込まれる点です。
各サービス間の連携を疎結合にすることで依存関係を明確にしておくことが重要なのですが、この考え方がDDDのコンテキストマップとマッチすることから、DDDとセットで扱われることが多いと思います。
やがて儚い幻想が壊される
ところが、各サービス間を疎結合に保つということがなかなか厄介になってきます。
例えば、リプレイス案件の場合であれば、現在のサービスをざっくりと（実はこれがいけないのですが）分析しドメインごとにマイクロサービス化してチームが結成される。
最初のころはドメイン分割してコンテキストマップで依存関係を明確にして設計＆開発が進むのですが、機能が増えてくると、どこのサービスの持ちものであるのかが難しくなってくる。
また、疎結合を保つためにイベントソーシングなどの手法を用いるケースも増えてくる。
同じ様なデータを各サービスが持つことも増えてきて、徐々に肥大化が始まってくる。
陰謀論
こうした挫折を経験すると、このような思考が頭をよぎる。
そもそも、マイクロサービスは本当に良いモノなのか。
マイクロサービスとはAmazonやGoogleのビジネス戦略なのではないか。
結局なにがダメだったのか考察してみる
最初に書いたのだけれど、マイクロサービスはDDDと相性が良いと思う。
DDDと相性が良いのでマイクロサービスはDDDと二人三脚で進めるべきなのではないか。
つまり、最初に細かく分割しすぎるのは良くないということ。
例えば、ユースケース駆動設計の手法を用いるのならば、ユースケース単位でドメイン分析を行い実装まで落とし込むことが可能である。
つまり、そのプロジェクトが最初にやらなければならないのはドメイン分割＆チーム割ではなくて、ユースケース（ユーザーストーリー）の洗い出しなのではないか。
言い方を変えてもう一度言うと、プロジェクトの最初期の段階では似たように見える機能を無理やりまとめてドメイン分けしてしまう必要はないのではないかということ。
いつ分割するのか。
初期リリースする機能のユースケースの分析（シーケンス）が終了したタイミング。
各ユースケースの依存関係やI/O、非機能要件がクリアになっているこのタイミングが理想的なんだと思った。
課題も勿論ある。
このタイミングでアーキテクチャ設計をして、マイクロサービス化して、サービスごとにチーム分けした場合、スケジュールはどうなっちゃうの？ということ。
そんなにゆったりしたプロジェクト存在しないよって言われそう。
10年後、マイクロサービスがどうなっているのか興味深い。