ドメイン駆動設計によるアーキテクチャ再構築

ドメイン駆動設計によるアーキテクチャ再構築～仕様を掘り起こし、意味の形へ～パーソルキャリア株式会社ﾃｸﾉﾛｼﾞｰ統括ｽｶｳﾄﾌﾟﾛﾀﾞｸﾄ開発部安田さくら 2025年8月26日 ※本資料は2025年8月時点の情報です

Copyright © PERSOL CAREER CO., LTD. All Rights Reserved. 2
会社概要社名本社創業資本金事業内容従業員数パーソルキャリア株式会社東京都港区 1989年6月 1,127百万円人材紹介サービス、求人メディアの運営、転職・就職支援、採用・経営支援、副業・兼業・フリーランス支援サービスの提供 7,048名（有期社員含むグループ会社出向中の者は除く 2025年3月1日時点）

3 Copyright © PERSOL CAREER CO., LTD. All Rights Reserved.
サービス概要

安田さくら新卒で印刷会社の開発部門に入り、教育関連のWebシステム開発を経験。 2023年にパーソルキャリアへ入社。「dodaダイレクト」のサービス改善フェーズに携わった後、現在はアーキテクチャ再構築プロジェクトに従事。宮城・仙台からフルリモートで参画しながら、DDDを学びつつ設計の現場で試行錯誤中。パーソルキャリア株式会社エンジニア自己紹介

01 背景と課題 02 取り組みの流れ 03 進め方の３ステップ 04 取り組みを通じて得られた学び１. ヒアリングをもとに大まかなモデリング２. コード起点での詳細モデリング３. 実装のフィードバックを反映 05 まとめとこれからの挑戦 • まとめ • 今後の展望

背景と課題

• dodaダイレクトは企業が転職希望者に直接スカウトできる法人向けサービス ◦ 日本最大級※1のスカウト会員データベースを活用し、サービス開始から急成長 • 既存の資産を活かしたスピード重視の開発により、事業は拡大 • その裏で、技術的な負債が蓄積されていった dodaダイレクトの急成長とその裏側 ※1 厚生労働省職業安定局人材サービス総合サイト（2023年1月時点）事業優先で走り抜けた先に、技術的な歪みが出てきていた

• 急成長の中で、課題が顕在化： ◦ 保守性の低いコード（密結合・共有DB） ◦ 不明確な仕様（属人化・ドキュメントの陳腐化） ◦ 分散モノリス構造（複数サービスが密に連携） • 背景には、事業優先・機能追加優先・人員の入れ替わり… → 品質維持に多大な工数がかかり、リードタイムやパフォーマンスにも影響わたしたちが直面していた課題保守性の低下不明確な仕様分散モノリスドメイン駆動設計を軸にしたアーキテクチャ再構築に踏み出した

• 経験豊富なエキスパートが先陣を切り、わたし自身はDDD未経験ながらモデリングチームのリーダに • 属人化した仕様・密結合なアーキテクチャ・共有データベース… • 教科書どおりにはできなそうだ • 仕様も不明確な状況でどう取り組みはじめればよいのか • 「組織で」導入していくにはどうしたらいいのか DDD導入は決まった！でも、どこからはじめよう？そんな現場でどう一歩を踏み出したかを共有します。同じような課題を持つ方々にとって少しでも参考になれば幸いです。

取り組みの流れ

どのように進めていったのかヒアリングをもとに大まかなモデリング ◦ これまでの資料や有識者へのヒアリングをもとに、大まかなモデリングを実施 ◦ ドメインを仮特定し、ドメインの関連を整理コード起点での詳細モデリング ◦ 詳細な仕様をコードから掘り起こす ◦ ロバストネス図に起こして、現在の仕様や関わるデータをとらえる実装のフィードバックを反映 ◦ モデリング結果を実装する ◦ フィードバックをもとに、モデルを更新する大まかなモデリング 1 詳細モデリング 2 実装のフィードバック反映 3

進め方の３ステップ１. ヒアリングをもとに大まかなモデリング２. コード起点での詳細モデリング３. 実装のフィードバックを反映

• 有識者へのヒアリング＋資料から全体像をモデリング • ドメインを仮に切り出し、関連を整理することで議論の土台を作った • 完成形を目指すのではなく、あくまで「探索のための地図」として活用最初の一歩はどこから始めたの？有識者の知見と資料をもとに、大まかな地図を描く図. 暫定のコンテキストマップ（ドメイン分割） dodaダイレクト図. 暫定のコンテキストマップ（ドメイン分割） 1. ヒアリングをもとに大まかなモデリング

• コードや画面操作だけでは「全体のつながり」が見えにくい • 画面操作やコードを読み解き、現在の仕様をロバストネス図※2に起こす ◦ Boundary：画面からユースケースのつながりを把握 ◦ Entity：現在のテーブルと対応。影響範囲を明らかに ◦ Control：分散した処理（SQL・関数）を捉え直す • 「画面設計書では見えない流れ」を可視化画面操作やコードをロバストネス図を使って流れを把握するロバストネス図のサンプル図. 現行仕様をロバストネス図に起こすコードを起点に、仕様を掘り起こす 2. コード起点での詳細モデリング ※2 ロバストネス図についてはAppendix「ロバストネス図とは」参照 dodaダイレクト

• 仕様を自然言語で記述 → モデルへ変換するプロセスを実施 ◦ 文章で仕様を表す：「ユーザーは◦◦できる」「システムは□□を保証する」 ◦ 現在の“実装の形”ではなく“意味の形”で捉え直せるようになった • コードやデータ構造は「実装の都合」が強く反映されている ◦ 意味が違うのに同じテーブルに入っているケース ◦ 意味が同じなのに別テーブルに分かれているケース • データモデルとドメインモデルのギャップを吸収する必要あり ◦ 乖離が大きい場合は変換用のモデルを挟むなど工夫して対応 ◦ それでも、ドメインモデルをデータモデルに寄せることも… 仕様を言葉にし、データモデルとの乖離を吸収するモデルを設計したモデルを整理するときの課題や工夫 2. コード起点での詳細モデリング

• モデルを試すため、一部実装してみた ◦ 実装するための設計の成果物として過不足ないか • 小さく作ることは必須 ◦ 失敗コストを抑え、素早く学びを得られる：メンバーの納得感 ◦ 小さすぎるとモデルの良さが出ないため、複数モデルや制約・ロジックが絡むユースケースで検証するのが有効 • 実装を通じて「机上の図」が「実際に動く設計」へと進化小さく試しつつ、複雑さを含むユースケースで検証すると効果的ソースコードドメインモデル PoC実装から得られた学び 3. 実装のフィードバックを反映

取り組みを通じて得られた学び

• 関わる人ごとに知識や視点が異なる ◦ DDDは初めてチャレンジするメンバーがほとんど ◦ 技術に詳しい人・業務を知る人・外部のパートナーなど多様なメンバーで構成されていた • 粒度が細かすぎても粗すぎても伝わらない ◦ コードレベルの詳細さは不要。でも、抽象的すぎても掴めない ◦ ロバストネス図を“共通の型”として採用 • 誰でも同じ土俵で議論できる助けとなる組織でモデリングを進めていく難しさ同じ土俵で議論するために、表現を型化した

• 現状のコードやデータ構造に引っ張られる ◦ これまでの経験で得た実装やデータ構造の知識が邪魔をする ◦ データベースは変えないという制約もあり、意味で捉えることは簡単ではなかった • 一方で、施策の背景や流れを理解する“ドメイン知識”は武器となった ◦ これまでの機能が作られた施策の背景や他プロダクトの繋がり、歴史などをよく知る力強い存在 • 技術的な知識と業務的な知識、その両方の橋渡しが必要だった知りすぎているからこその「意味で捉える難しさ」コードやデータの知識を“意味の世界”へ橋渡しする

まとめとこれからの挑戦 • まとめ • 今後の展望

• 不確実な状況でも、仮説ベースでモデリングを始めた • 不明確な仕様に対して、コードや画面操作から掘り起こし、意味で捉え直した • 小さく試し、フィードバックをもとにモデルを進化させた • 更新を「手戻り」ではなく「進化の前提」として捉える視点が重要だった • DDDを組織で実践するには、プロジェクト全体での理解と支援が不可欠まとめ：進める中で見えた「得られたもの」小さな工夫と苦労の積み重ねが、進化を支える

• モデルと実装を往復させるサイクルの手応えを得た • 共有DBや密結合などの課題を踏まえ、マイクロサービス化を見据えた越境の取り組みへ • 複数プロダクト横断でイベントストーミングを実施 • 今後はAI活用も本格化 • モデリングやコーディングの現場でもAIを味方にまだまだ挑戦は続いていく学びを武器に、全体展開と新しい時代へ

エンジニアブログのご紹介さまざまなテーマで事例や知見を学ぶ IT・テクノロジー人材のための勉強会コミュニティ「TECH Street」当社の事例を公開しています。「techtekt（テックテクト）」は、パーソルキャリアのエンジニアブログです。 “みんなの「はたらく」をテックでつくる”をコンセプトに、技術、組織、学びなど、さまざまな情報を発信しています。

24 ご清聴ありがとうございました【免責事項】本資料に含まれる技術情報は発表日時点のものであり、予告なく変更される場合があります。実装や運用は自己責任で行ってください。発表者および所属組織は、本資料に基づく行動の結果について一切の責任を負いません。本資料に記載されている会社名・製品名などは、一般に各社の登録商標または商標、商品名です。資料内では ©, ®, TM
マークなどは表示していません。

Appendix

Appendix：ロバストネス図とはルール • 名詞は動詞とつなぐことができる（逆もまた同様） • 名詞をほかの名詞につなぐことはできない • 動詞はほかの動詞につなぐことはできないロバストネス図ユースケースの振る舞いを視覚的に整理するための図です。構成する要素 • Boundary（境界）：ユーザーインターフェースや外部との接点 • Entity（実体）：業務上のデータやオブジェクト • Control（制御）：処理の流れやロジックを担う部分図. ロバストネス図を構成する要素図. ロバストネス図の例

27 Appendix：取り組みの流れ dodaダイレクト dodaダイレクト Handler Domain Model Repository ステップ1. 資料や有識者ヒアリングから、大まかなモデリングを実施。暫定のコンテキストマップを作成ステップ2.コード解析し、ロバストネス図を用いて流れや仕様可視化エンティティと現在のテーブルをマッピング優先付けやタスクの分担にも役立つ U D D U 大まかなドメインモデル暫定のコンテキストマップロバストネス図で仕様理解ドメインモデルを詳細化実装巨大な共有DB ステップ3. 一部のユースケース実装し、設計の妥当性を検証。フィードバックに応じてモデルを更新する現行のソースコード解析

ドメイン駆動設計によるアーキテクチャ再構築

ドメイン駆動設計によるアーキテクチャ再構築

PERSOL CAREER Dev | techtekt PRO

More Decks by PERSOL CAREER Dev | techtekt

Other Decks in Technology

Featured

Transcript