背景

前提として、マネーフォワードクラウド会計(以後、クラウド会計と表記)をマイクロサービス化しなければ、となったとき以下のような背景がありました。

クラウド会計のリポジトリ巨大化によって、開発速度が低下する
そのリポジトリをメンテナンスし続けることでひとつの技術に縛られることになり、技術者のスキル向上につながらない
さらに、マネーフォワード全社で部分的にマイクロサービス化していくぞという流れが後押し
- マネーフォワードCTOが考えていること（2020年3月）

マイクロサービス化によって開発速度が向上し、最終的にユーザ価値につながるためこのような意思決定をしました。しかし、マイクロサービス化するといっても、いきなり設計ができるわけではありません。

特に難しい点は分割粒度で、そこで最初に取り組んだことを紹介していきます。

結論

あるべき論の 未来図 と、データの流れである データフロー図 を整理しました。

見える化することで意思決定の根拠が集まるため、さらに次のアクションが決まりやすくなります。

また、各種方面からのフィードバックが集まり、エンジニアだけでは決められないビジネス要件についてもご意見を聞きやすくなるメリットがあります。

未来図

コンテキストマップに近いものですが、システムやDBまで意識した図になっており、未来図という名前で進めてきました。

2021年初期の段階で、少し先にどんなサービスが生まれるかをヒアリングして図にしたのがものです。

ヒアリング先は主に次のとおりです。

プロダクトオーナー
ドメインエキスパート（会計知識のある専門家）
関係するエンジニアチーム

プロダクトの新機能開発計画との兼ね合いにより、他チームサービスとの連携部分でどう使われるかを判断して未来図に組み込むかが非常に難しい点でした。関係者が多いため、この未来図作成には時間を要します。関係者全員の時間をド短期集中確保できれば終わるかもしれませんが、そうも行きません。

こちらは完成までに3ヶ月〜半年かかっています。 (さらに、この未来図は影響先がわかるように2021年末にも訂正版を作成し、実際にどこまで何が進んだのか？を見える化しています。)

これにより、大まかな構成はみえました。

ただしこれは、各サービス視点でのデータの流れは抽象化されすぎています。もう少し踏み込むことで、まだ見えていない気づきがあるのではないかと思いました。

そこで、データフロー図を作成することにしました。

データフロー図

各サービス視点からデータの流れを見える化する事で、俯瞰して気づけなかった観点を洗い出す目的です。

作成した結果、以下のようなメリットが有りました。

一部のユースケースレベルでのデータの流れ
中間データを作成するべきか？という議論にまで発展できた
- 実際のマイクロサービスの設計に踏み込んだ議論が可能になる
Pub/Sub構成の方が良いね、という話を各関係者（エンジニア以外のメンバ―含め）と会話ができた
- 未来図とデータフロー図によって、エンジニア以外のメンバーと議論できたのは大きなメリット

これで、マイクロサービス化設計する準備が整いました。

以降は、各チームで詳細設計が開始される想定です。その中で不都合があれば、データフロー図または未来図にそれぞれ立ち戻って、関係者と調整を実施することで十分ワークするでしょう。

感想

今回はマイクロサービス化に対する設計でしたが、今後はコードに適用する部分でも同じ設計の課題感が強まってくると予想しています。個人的に、BtoB SaaSは特にコンテキスト境界が曖昧になりがちな課題を抱えていると考えています。

これらの課題を解決し、さらにスピードを上げて価値を提供できるために引き続き、設計に対して挑んでいければと思います。

そして、マイクロサービスは手段であり目的ではありません。 弊社の場合、目的を達成するためにマイクロサービス化を進める判断が既になされていましたが、まずはこの目的設定が最重要だと考えます。

おわりに

今年は、マイクロサービスの構成を検討するために、走り回った一年でした。いろいろな書籍を読んだり、DDD詳しい方へコンタクト取ってみたり、アドバイザーを募集したり、各種勉強会にお邪魔したり。そんな中、DDDの知見はコード外でも十分に力を発揮することがわかり、今回の手法を進める上でとても参考になりました。

興味を持ったかたはぜひカジュアル面談しましょう！設計沼なお話を聞かせてください！ twitter DMでも、下記募集から応募いただいても大丈夫です。【アーキテクト】マネーフォワードクラウド_東京（田町）

最後までお読みいただきありがとうございました。