DDD × クリーンアーキテクチャで学ぶ 疎結合設計と生成AI活用 (20260801).pptx

システム移行案件 技術基礎講座 DDD × クリーンアーキテクチャで学ぶ 疎結合設計と生成 AI活用 新人〜中堅エンジニア向け ／ 技術面談での説明力強化を目的とした資料 背景 うさうさ研修工房 DDD Clean Arch 移行実践 AI活用 面談対策

01. 背景 なぜ今、疎結合化が必要なのか ▪ 長年運用中の基幹システムほど、周辺システムとの間に複雑なデータ参照が積 み重なり、影響範囲が読みにくくなる 密結合 → 疎結合（イメージ） Before：密結合 ▪ この状態を「密結合」と呼び、一箇所の修正が想定外の箇所に波及するリスクを 高める ▪ 新規自社開発システムへの移行は、既存システムを止めずに少しずつ置き換え る段階的な進め方が求められる 周辺A 既存 基幹システム 周辺B 周辺C ▪ その設計の拠り所が、 DDD（ドメイン駆動設計）とクリーンアーキテクチャという 2つの考え方 After：疎結合（ Clean Architecture） ドメイン (中心) うさうさ研修工房｜システム移行 技術基礎講座 アダプタ経由で周辺と接続 2

02. DDDの基礎 DDDとは — 「業務の言葉」を設計に落とし 込む ▪ DDD（ドメイン駆動設計）は、業務そのものの知識（ドメイン）を出発点にソフトウェ アを設計する考え方 ▪ ユビキタス言語：現場担当者とエンジニアが同じ言葉で会話できるよう、用語を設 計・コードに統一する ▪ 境界づけられたコンテキスト：業務領域ごとに意味の境界を区切り、同じ言葉でも 文脈が違えば別モデルとして扱う ▪ 36件の査読済み研究を分析した文献レビューでは、DDDはシステムの改修・再構築 において有効に機能したと報告されている 境界づけられたコンテキスト 受注 ユビ キタ ス言 語で 橋渡 し 在庫 会計 同じ「商品」でも文脈ごとに意味・属性が異なる うさうさ研修工房｜システム移行 技術基礎講座 3

03. Clean Architectureの基礎 クリーンアーキテクチャ — 変化に強い同心 円構造 ▪ Robert C. Martin氏が提唱した設計思想。システムを同心円状の層に分け、依存 の方向を「内向き」に固定する ▪ 中心は業務ルール（Entities／Use Cases）。外側のUI・DB・フレームワークが変 わっても中心は影響を受けない 依存は外 → 内のみ 依存 依存 ▪ この依存規則により、フレームワークやDBの入れ替えが容易になり、テストもし やすくなる ▪ 複雑で変化の多いシステムほど、この構造の恩恵が大きいと業界解説記事の多くが 指摘している Entities Use Cases Interface Adapters Frameworks & Drivers うさうさ研修工房｜システム移行 技術基礎講座 4

04. 移行の実践 密結合から疎結合へ — 段階的リプレイスの 進め方 ▪ 一括で作り直す「ビッグバン移行」はリスクが高く、長年運用中のシステムには不 向き ▪ 「ストラングラー・フィグ・パターン」は、新旧システムを併存させながら機能単位で 少しずつ置き換える手法 ▪ DDDとストラングラー・パターンを組み合わせた移行手法が、実システムへの適 用事例として研究報告されている 既存システムの縮小推移（イメージ） Step 1 受注を切出し Step 2 在庫を切出し ▪ 境界づけられたコンテキストの単位が、そのまま移行の切り出し単位（サービ ス境界）の目安になる Step 3 会計を切出し 既存システム うさうさ研修工房｜システム移行 技術基礎講座 新システム 5

05. 依存関係分析 依存関係の可視化と移行用疑似データベー ス ▪ 既存システムと周辺システムの間で「誰が」「どのデータを」「どう参照しているか」 を洗い出すことが疎結合化の第一歩 依存関係マップ（イメージ） ▪ 接続先変更やデータ移行の影響調査では、参照元・参照先の一覧化と波及範囲 の見積もりが欠かせない 顧客DB ▪ 本番データに触れずに検証できるよう、移行用の疑似データベース（模擬データ 環境）を設計・構築し移行リハーサルを行う 在庫API ▪ この検証工程を経ることで、本番切替時のトラブルを事前に減らすことができ る 既存 システム 会計I/F 帳票基盤 金色＝今回の接続先変更で影響を受ける経路 うさうさ研修工房｜システム移行 技術基礎講座 6

06. 生成AIの活用 生成AI（Claude）を設計・開発にどう活かす か ▪ 海外の研究では、複数の大規模言語モデルにコードのリファクタリングを行わ せ、人間の開発者と比較する実験が行われている ▪ 機械的に検出できる問題の改善は AIが得意とする一方、文脈に依存する複雑な 判断は依然として人間が優れているという傾向が報告されている ▪ つまり AIは「代替」ではなく「壁打ち相手・下調べ役」として活用し、最終判断は エンジニアが行うのが実務的なスタンス うさうさ研修工房｜システム移行 技術基礎講座 設計〜開発フローと AIの関与度 要件整理 人が判断 設計たたき台 AI支援 影響調査 AI支援 実装 AI支援 レビュー／判断 人が判断 7

07. 面談対策 技術面談で「説明できる」ようにしておく ▪ 求人票にもある通り、設計経験は「なぜその設計にしたか」を言語化できるかが 問われる ▪ 「なぜDDDだったのか」「なぜクリーンアーキテクチャだったのか」という判断理由 と、採用しなかった選択肢とのトレードオフも説明できるようにする ▪ 生成AIをどう使ったか（どこを任せ、どこを自分で判断したか）も具体例を1つ用意 しておくと強い STARで経験を 1つのストーリーに S T A R うさうさ研修工房｜システム移行 技術基礎講座 状況 密結合な基幹システムの運用課題 課題 改修コストとリスクの増大 行動 DDD/Clean Architectureで疎結合化 結果 改修範囲の限定・テスト容易性向上 8

08. まとめ まとめ — 疎結合設計がもたらす価値 ▪ DDDは「業務の言葉」を軸に、境界づけられたコンテキストでシステムの意味の境 界を整理する考え方 ▪ クリーンアーキテクチャは「依存の方向」を内向きに固定し、変化に強い構造をつ くる考え方 ▪ 両者とストラングラー・パターンを組み合わせ、段階的に移行することでリスクを 抑えながら密結合を解きほぐせる ▪ 生成AIは工程を加速させる相棒。最終的な設計判断とその説明責任はエンジ ニア自身が持つ 3つの要素が組み合わさる DDD Clean Architecture 生成 AI活用 リスクを抑えた 段階的な移行 うさうさ研修工房｜システム移行 技術基礎講座 9

参考文献 参考文献・出典 Özkan, O., Babur, Ö., & van den Brand, M. (2025). Domain-Driven Design in software development: A systematic literature review on implementation, challenges, and effectiveness. Journal of Systems and Software, 230, 112537. https://arxiv.org/abs/2310.01905 Li, C.-Y., Ma, S.-P., & Lu, T.-W. (2020). Microservice Migration Using Strangler Fig Pattern: A Case Study on the Green Button System. 2020 International Computer Symposium (ICS), IEEE. https://ieeexplore.ieee.org/document/9359092/ Cordeiro, J., Noei, S., & Zou, Y. (2024/2026). An Empirical Study on the Code Refactoring Capability of Large Language Models. ACM Transactions on Software Engineering and Methodology. https://arxiv.org/abs/2411.02320 うさうさ研修工房｜システム移行 技術基礎講座 ※ 記載内容は各論文・記事の要旨に基づき要約したものであり、詳細は各 URL先の原典をご確認ください。 10

• https://arxiv.org/abs/2310.01905
• https://ieeexplore.ieee.org/document/9359092/
• https://arxiv.org/abs/2411.02320