ドメイン駆動設計によるdodaダイレクトのリビルド実践 / Rebuild practice of doda direct with domain-driven design

Transcript

1. ドメイン駆動設計による dodaダイレクトの リビルド実践 分散モノリスからの脱却 ©PERSOL CAREER CO., LTD.
2. 会社概要 2 パーソルキャリア株式会社 東京都港区 1989年6月 1,127百万円 人材紹介サービス、求人メディアの運営 転職・就職支援、採用・経営支援サービスの提供 6,929名 （有期社員含む グループ会社出向中の者は除く 2024年3月1日時点）
3. 自己紹介 3 ©PERSOL CAREER CO., LTD. 名前 ：池田 庸一 略歴 基幹系のエンタープライズシステムからSaaSに至るまで、様々なシス テム開発を経験し、2023年9月にパーソルキャリアに入社。 10年ほど前からドメイン駆動設計に興味を持ち、実務に取り入れて実 践。現在はシニアエンジニアとしてプロジェクトを牽引。
4. プロジェクトの概要 「doda ダイレクト」は、企業が転職希望者様に直接スカウトを行うダイレクト・ソーシングサービ スです。市場の成長が見込まれる中で、機能の拡充やユーザーの増加に対応する必要があります。 しかし、技術負債が大きく、リファクタリングでは対応が難しくなってきました。 そのため、アーキテクチャの再構築が急務となっています。 成長に伴う品質や生産性の問題を解決するために、システムを根本から見直しています。現在はま だ初期フェーズで製造に入ったばかりですが、同様の課題を抱える皆様の参考になれば幸いです。 4 ©PERSOL CAREER CO., LTD.
5. アーキテクチャ再構築の理由 5 事業の立ち上げ優先 保守性の低いコード ドキュメントの陳腐化 人員の入れ替わり 不明確な仕様 密結合なアーキテクチャ 分散モノリス 品質維持工数の増加・リードタイム増加・パフォーマンス低下 機能追加優先 共有データベース 小手先のリファクタリングでは対応ができなくなってきた 解決すべき重要な課題 ©PERSOL CAREER CO., LTD.
6. アーキテクチャ再構築のアプローチ 6 不明確な仕様 技術負債 仕様の掘り起こし リビルド コード解析 + ドメインモデリング DDDアーキテクチャ で再構築 ドメイン駆動設計 インクリメンタルに 仕様理解できる。 インクリメンタルな 製造できる。 保守性の低いコード + 分散モノリス ビッグバンリリース わずかな修正が波及するため ストラングラーパターンの 適用がリスクとなる。 ©PERSOL CAREER CO., LTD.
7. 仕様の掘り起こし 7 ©PERSOL CAREER CO., LTD.
8. 不明確な仕様に立ち向かう 8 大雑把なドメインモデリング •概要レベルの モデリングを行い 業務理解 ドメイン分割 •モデルをグループ化し ドメイン分割 •コンテキストマップの 作成 ソースコード解析 •スコープを絞って解析 ドメインモデルの詳細化 •ソースコードの解析結果からモデル の精度を高める コーディング ©PERSOL CAREER CO., LTD.
9. 不明確な仕様を理解する-コンテキストマップ 9 理解が困難なモノリスコード 大雑把なドメインモデリングと ドメイン分割 (暫定版)コンテキストマップ 仕様理解の足場となる マイクロサービスの設計につながる ©PERSOL CAREER CO., LTD.
10. コンテキストマップからモデリング詳細化 10 コンテキストマップ ソースコード ドメインモデル DBテーブル テーブルマッピング 解析結果から モデル詳細化 必要に応じて コンテキストマップを更新 荒いドメインモデルにソースコード解析の 結果を反映させることで精度を上げていき ます。 ©PERSOL CAREER CO., LTD.
11. アーキテクチャ 11 ©PERSOL CAREER CO., LTD.
12. アーキテクチャの考慮ポイント • DDDと相性が良いこと – 思想と噛み合わない技術は負債となりえる • 生産性が高いこと – 生産性が高いシステムは単純で品質が良い • 標準的な技術であること – 標準的な技術は長くサポートされる – 他の技術との組み合わせに自由度が高くなる 12 ©PERSOL CAREER CO., LTD.
13. 現在のアーキテクチャ • EC2でホスティングされたモノリス構成 – 泥団子となりリファクタリングが難しい • SPAアプリケーション – APIと密結合している • 共通DBでデータを共有 – 分散モノリス化 – スケーリングが難しい ©PERSOL CAREER CO., LTD.
14. 再構築後のアーキテクチャ • マイクロサービスアーキテクチャ • フロント向けのサービス統合 – 各ドメインはマイクロサービス化しGraphQL APIを公開し サブグラフを構成する – Apollo Federation(AF)でサブグラフを統合しスーパーグラ フを構成する – AFがBFFとなるためBFFの実装が不要になる • バックエンドの統合 – Daprをサイドカーで設置し分散処理を移譲する – イベントソーシングはDaprのpub/subを利用して実装 – イベントはSAGAで一元的に受信し各サービスをオーケスト レートする • dodaダイレクトのコアドメインであるスカウトは独自DB で管理 • スカウト以外のサービスは腐敗防止層として他サービスと の依存性を下げる 14 ©PERSOL CAREER CO., LTD.
15. 再構築後のアーキテクチャ – 各サービス • CQRSアーキテクチャ • GraphQL – Query/MutationがCQRSと相性が良い • GraphQL–Query - Query Stack – RESTfulで問題となるN+1問題やOver Fetch/Under Fetchを解決できる – Query Model • 型付けしてドメインモデルの構造を表現 – 結果的にフロントエンドと疎結合化される – 浅いレイヤーで実装する • GraphQL–Mutation - Command Stack – ドメイン知識が流出しないようにMediatorで実装 – イベントメッセージの送信はDaprに移譲 • Daprは送信トレイパターンなどの実装を提供 15 ©PERSOL CAREER CO., LTD.
16. 選定技術 – マイクロサービス 【選定理由】 • DDDとの相性 – ドメイン分割されたコンテキストはマイクロサービス へマッピングできる。 • メンテナンス性の向上 – ソースコードが小さくカプセル化されメンテナンス性 が向上する。 • スケーラビリティの向上 – ドメインごとにスケールを調整できる。 • 技術の選択肢が広がる – サービスごとに技術を柔軟に選択できるようになる。 16 ©PERSOL CAREER CO., LTD.
17. 選定技術 - GraphQL 【選定理由】 • DDDとの相性 – ドメインモデルを表現した型付けされたAPIモデルを 公開できる。 – CQRSとの相性が良い。 – マイクロサービスを自然な形で統合できる。 • 標準化 – GraphQL Foundationにより標準化されている。 • 通信効率が良い – N+1問題、オーバーフェッチ・アンダーフェッチ問題 を回避できる。 • 生産性の向上 – 各サービスで公開されたGraphQLを統合しスーパー グラフを構成できる。 – BFFとして機能するため改めてBFFの実装が不要 – 型付けされたスキーマが公開されAPIドキュメントと なるため理解が容易。 17 ©PERSOL CAREER CO., LTD.
18. 選定技術 - イベントソーシング 【選定理由】 イベントソーシング • DDDとの相性 – ドメインイベントの概念と一致する。 • システム間を疎結合にできる。 SAGA • 結果整合性を実現するためのイベント駆動のワークフローを実 現。 Dapr • CNCFプロジェクトの一つでベンダーニュートラル。 • 様々な開発言語で利用できる。 • 送信トレイパターンや状態管理など分散システムに必要な難し い処理を提供してくれる。 18 ©PERSOL CAREER CO., LTD.
19. 選定技術 – 開発言語 C# 【選定理由】 • リソースの確保の行いやすさ – Javaと並び国内で利用者が多い。 – 現行システムもC#で作られているため開発者のスライドができる。 • DDDとの相性 – 静的型付のオブジェクト指向言語。 – 実装に必要なパッケージが豊富に存在する。 • 開発言語の魅力 – 関数型言語機能やパターンマッチングなどモダンな言語仕様。 – マルチプラットフォーム。 – 低消費メモリで高速に動作する。 – 生産性を高めるエコシステムが揃っている。 (Visual Studio/.NET Aspireなど) 19 ©PERSOL CAREER CO., LTD.
20. 再構築ごとのアーキテクチャ – 共有DBからの脱却 20 • 現行DB(共有DB)への読み書き • アーキテクチャ移行のみ • 独自の新DBへデータ移行 • 切り戻しが出来るように 現行DB (共有DB) /新DBへの同時 書き込み • バグが発生していないことが確認 されたら現行DB (共有DB)への書 き込みを廃止 Ph1 アーキテクチャ移行 Ph2 独自DBへデータ移行 Ph3 現行DBの廃止 コアドメインのデータは独自DBに移行します。移行リスクを最小限にする必要があります。 移行理由 • スケールが難しい • シングルポイント • 他と共有されているため容易に変更ができない など ©PERSOL CAREER CO., LTD.
21. 成果・学び・取り組み 21 ©PERSOL CAREER CO., LTD.
22. 成果 - 複数手段によるモデリング精度向上 本プロジェクトの悩みのタネは明確な仕様が わからないということ。 信頼できる情報源がないため複数の情報源か らモデリングを行い精度を向上させています。 22 ©PERSOL CAREER CO., LTD.
23. 成果 -コンテキストマップによる領域の明確化 精度が高まっていくと サービスの責務や依存性が明確になりました。 モノリスサービスから比べると依存性が軽減され ました。 ここまでくるとコアドメインのデータを独立する 目処が立ってきました。 分散モノリスは回避できそうです。 23 ©PERSOL CAREER CO., LTD.
24. 成果 -ドメインごとの特徴が明らかに ドメインごと業務の特色が違うことが明らかになりました。 それによってシステムの最適化に差が出てくることが想定で きます。 求人 - 企業ごとに管理するが求職者も参照が可能 - 外部システムのデータを参照するのみ 求職者 - 検索性が重要 - データ自体は外部のシステムから取得する - 回覧者により情報を制限 スカウト - 企業ごとのテナント管理 - スカウト活動を管理するメインとなるドメイン 24 ©PERSOL CAREER CO., LTD.
25. 成果 - GraphQLによる参照問い合わせ単純化 GraphQLのリファレンス実装に基づき、 実装を行うことで 実装が単純化しました。 25 ©PERSOL CAREER CO., LTD.
26. 活動 - モデラーの育成 26 ドメイン駆動設計はドメインモデリングが全てのスタート 地点となります。 ペアモデリングやディスカッションを通じて育成。 最重要テーマとして取り組んでいます。 ©PERSOL CAREER CO., LTD.
27. 苦労 - ドメインモデルとデータモデルの乖離 さまざまな情報から書き起こしたドメインモデルと データモデルの乖離が大きい。 データ変換ロジックが複雑化 ドメインモデルをデータモデルに寄せるなどの妥協 で調整 27 ©PERSOL CAREER CO., LTD.
28. ©PERSOL CAREER CO., LTD. 最後に 28
29. アーキテクチャ再構築後の展望 ©PERSOL CAREER CO., LTD. 29 コアドメインの マイクロサービス化による 自由度と生産性の向上 技術最適化による パフォーマンスの向上 企画・開発チームが ドメインモデルを中心に 設計開発を行っていく
30. まとめ ドメイン駆動設計を採用した既存システムのリビルドについて紹介しました。 • 不明確な仕様を掘り起こすにはコンテキストマップの作成は重要 – ドメインを分けることで理解が進む。 – 技術の選択肢が増える。 • GraphQL – ドメインモデルを表現しBFFとして機能するため生産性を向上させます。 • イベントソーシング – サービスを疎結合に連携させます。 • モデラーの育成 – DDDにおいてキーパーソンとなります。出来る人を増やしましょう。 駆け足でしたが、ご清聴ありがとうございました。 30 ©PERSOL CAREER CO., LTD.