個人開発シリーズ3：設計（v0.1）
こちらの記事の続きになります。
今回は開発を進めるにあたってもう少しイメージを固める必要があったので、アーキテクチャ図や各コンポーネントの設計をざっくり行ってみました。
アーキテクチャ図
ひとまずざっくりしたアーキテクチャ図はこんな感じのイメージで設計しました（前回のコンテキストマップのCore部分のみ）。細かい話は後半で書いてます。 各サービス間連携の部分等、より詳細の部分はまた後ほど載せていこうと思います。
APIゲートウェイ
バックエンドのマイクロサービスアプリケーションへのエントリとなるサービスになります。 ここではリクエストのルーティングやAPI合成、認証などを担当します。
前回の記事のドメインモデル図で、UserはAuthenticationコンテキストにも所属していましたが、Authentication.Userドメインの責務はここに関わる部分なので、あえて個別サービスを作るのではなくAPIゲートウェイの中でその役割を実装することにします。
また、認証周りは自前実装は避けたいところですし、Firebase Authenticationという優秀な認証基盤もあるのでこれを使って認証・認可を行います。
マイクロサービス
本来、開発当初にマイクロサービスアーキテクチャを選定することはあまり良い選択肢ではなく、最初はモノリスでスタートさせて組織の拡大とともにマイクロサービスに移行する方が適切なのが一般的です。 その方がドメインに対する知識も溜まっており、適切なサービス分割を行うことができます。
ただし、今回は勉強目的でもあるので最初からマイクロサービスを採用することにしています。知見のない状態でサービス分割を進めることになるので、ここでは明確な境界を引ける部分のみでサービス分割を行っていくことにします。 開発を進めていく中でもし粒度が大きい場合はその時に分割することにするとします（個人開発なのでそもそも分割する必要なんてないんですが、そこはまあ仮想的にです）。
サービス分割の指針
まず考えられるものとしては、コンテキストが異なるものは分割して考えられることがわかります。
さらにコンテキスト内にあるドメインモデルに境界を引いていきます。この時、一般的にはアグリゲート（集約）が明確な境界となります。アグリゲートの識別もドメイン知識がない状態では難しいのですが、アグリゲートは整合性の単位であり、以下のルールがあります。
- 外部からはアグリゲートルートだけを参照する
- アグリゲート間の参照では主キーを使わなければならない
- 1つのトランザクションで1つのアグリゲートを作成または更新する
これらを意識して開発を行うことを想定しつつ、現状でわかる範囲でサービス分割を行いました。
サービス分割
以上の指針の中で、ひとまずCoreコンテキストについて進めます。
まず少なくともUserは一つのアグリゲートととして考えることができそうなことがわかります。 また、本ツールの重要な概念であるInvestmentItem（投資案件）をアグリゲートルートとした投資案件サービスも考えます。UserはInvestmentItem（投資案件）をリストを保有していますが、idをリストとして持つことでルール2を満たせます。
また、InvestmentItemとCompanyおよびDealSourceも整合性の単位として一つではないと容易に想定できるため、分離して考えます。
「InvestmentItemとDueDiligence〇〇」および「UserとPerformance」は正直現時点で判断するには知識不足であるため、ひとまず同じアグリゲートに属すものとして考えてみようと思います。
ここまでをまとめると、以下の図の通りになります。実線はオブジェクト参照、点線は主キー参照です。
それでは大体開発に入るための指針が整ったので開発に入っていこうと思います。 次回はようやくコードを載せられると思います。
