こんにちは、技術本部 Sansan Engineering Unit Data Hub グループの秋田です。
私は現在、Sansan Data Hubのリアーキテクチャに取り組んでいます。
本連載ではそのリアーキテクチャの裏側に迫ります。
第1回となる本記事では、新アーキテクチャにおけるドメイン分離についてご紹介します。
リアーキテクチャの背景
Sansan Data Hubは長年の開発と運用で、以下の問題が顕在化していました。
- 新規機能の開発が遅い
- 運用負荷が高い
設計の肥大化・複雑化により、改修やエラー時の原因特定の難易度が上昇し、開発の遅さや運用負荷の高さに繋がっていました。リアーキテクチャではこれらの問題に対して設計レベルから向き合っています。
過去の取り組みと課題
Sansan Data Hubの開発メンバーは20名前後おり、3～4人単位のチームに分かれていました。もともとは全チームが全ドメインを横断的に扱うスタンスで、どんな改修タスクでも柔軟にアサインできるよう、ドメインごとの担当は設けていませんでした。
しかし、アーキテクチャの肥大化・複雑化に伴い、全体の把握が難しくなってきたため、「ドメインごとに担当チームを分ける」運用を試みました。ただ、これは期待通りに機能しませんでした。
主な理由は以下の2点です。
- ドメイン間の結合度が高く、担当外ドメインの知識も必要
- 改修タスクを適度な粒度でドメイン単位に切り分けられなかった
現アーキテクチャはマイクロサービスアーキテクチャを採用しているものの、ドメイン間のインターフェースが明確でなく、あるドメインの変更が別ドメインに思わぬ影響を及ぼすケースがよくありました。そのため、担当外ドメインの知識も必要になっていました。
また、一部ドメインが肥大化しておりどの改修タスクでも触らざるを得ないことが多かったです。おまけに結合度の高さも相まって、改修は複数ドメインをまたがりがちでした。ドメインごとに担当チームを細かく分けるとコミュニケーションコスト増加に繋がるため、小規模な改修なら担当外のドメインも含めて1つのチームがまとめて担当するケースがほとんどでした。
新アーキテクチャでの取り組み
今回のリアーキテクチャでは「チーム分割とアーキテクチャのドメイン分割を両面から見直す」アプローチを採用しました。具体的には以下の手順でドメイン分割を行なっています。
- ユースケースベースでイベントストーミング*1行い、 Bounded Context*2 を定義
- 各ドメイン間のインターフェースの明確化
- 関連性の高いドメインをチーム単位（6～8 人構成）でグルーピング
- 上記プロセスを繰り返しブラッシュアップ
一部ドメインの肥大化についてはドメインを細かく分け直すことで対応しています。
また、次の処理にメッセージを送信する際、これまではメッセージに下流の全ての処理に必要なデータを含めていたため、インターフェースが不明瞭でした。そこで、メッセージにはIDのみを載せてデータは問い合わせる方式にしています。従来は下流にある全ての処理のニーズや振る舞いを考慮する必要がありましたが、新しい方式では必要な処理のみが必要最小限のデータのみを取得する形になるので、変更による影響範囲を限定しやすくなります。
さらにチーム構成も見直す予定です。以前の3～4人単位から6～8人に拡大し、関連性・類似性の高いドメインをグルーピングしたものを割り当てようと考えています。これによりタスクの割り当て柔軟性を確保しています。
まとめ
今回はリアーキテクチャにおけるドメイン分割の取り組みをご紹介しました。
本連載では今回のドメイン分割の成果も含め、今後もSansan Data Hubのリアーキテクチャの進展をお届けしていく予定です。お楽しみに！
Sansan技術本部ではカジュアル面談を実施しています
Sansan技術本部では中途・新卒採用向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話します。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
