Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地

Sponsored · Your Podcast. Everywhere. Effortlessly. Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
Avatar for imkaoru imkaoru
October 07, 2025

Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地

Avatar for imkaoru

imkaoru

October 07, 2025
Tweet

More Decks by imkaoru

Other Decks in Programming

Transcript

  1. © dip Corporation.. Agenda 1. ⾃⼰紹介 2. 会社概要 3. 前提:所属チーム‧⽬的‧開発体制

    4. ドメイン駆動設計について 5. GoとDDDの相性 6. ドメインモデルの実装 7. 開発課題と取り組み事例
  2. © dip Corporation. 佐藤 薫 2023年4⽉ 新卒⼊社 プロダクト開発統括部 / バイトルエンジニアリング部

    Go歴:⼊社とともに DDD歴:5⽉〜 福岡歴:⼤学から。就職を機に⼀度東京へ⾏き、昨年9⽉に戻る 最近楽しかったこと:スクラム祭り!!
  3. × Human work force solution ユーザーファーストな独⾃機能を搭載した、 求⼈情報‧⼈材紹介サービスの提供を通じて、 ユーザーの就業課題を解決しています。 ⼈材サービス事業 Digital

    labor force solution バイトコミュニケーションアプリ『バイトル トーク』や、機能を絞ったシンプルなSaaS型の 『コボット』を通じて、職場環境やコミュニ ケーション課題を解決しています。 DX事業
  4. © dip Corporation. 前提:所属チーム・役割・開発体制 9 • 所属チーム :新規プロダクトのAPIプラットフォームチーム • チームの役割

    :変更容易性の高いAPIを作成し、素早い仮説検証 サイクルを回せるものづくり体制を実現すること
  5. © dip Corporation. ドメイン駆動設計について 15 重要な概念 • 戦略的設計と戦術的設計 ◦ Why・WhatとHowの関係性

    • 業務領域(サブドメイン ) ◦ 事業目標を達成するために、事業活動を分析することを目的にドメイン を細分化したもの ◦ 建設的に手を抜いて、中核領域に集中できるように業務領域を分類す る • 境界付けられたコンテキスト (BC) ◦ ソフトウェア設計の視点から事業活動モデルを扱いやすい単位にするた めに、ドメインを分解したもの
  6. © dip Corporation. ドメイン駆動設計について 16 ドメインモデルとは ◦ 中核の業務領域を対象に、複雑な業務ロジックを扱うための設計手法 業務ロジックとは ◦

    業務領域におけるルールや前提条件、制約 ◦ 値オブジェクト、集約、業務サービスで扱うドメインに関するロジックの総称
  7. © dip Corporation. Go と DDD の相性 19 • シンプルで明示的な言語仕様

    ◦ 暗黙的な魔法が少なく、意図をコードにそのまま表現できる • 後方互換性の高 さと豊富な標準ライブラリ ◦ ドメインロジックの継続的な改善に集中できる ◦ ドメインモデルのような単純なオブジェクト中心の設計と本質的に相性が良い • 設計の自由度と制御性 ◦ フレームワークに縛られず、アーキテクチャを自分たちのドメインに合わせて構築でき る
  8. © dip Corporation. 20 Go と DDD の相性 依存関係逆転の原則 ◦

    Goのinterfaceは、ポートとアダプターの分離を自然に表現できる 実装ではなく抽象に依存する構造(依存の整合性)を型システム自体で保証できる
  9. © dip Corporation. ドメインモデルの実装 22 実装例のテーマ • 「AIを使用し、ユーザーの悩み解決におすすめの書籍をピックアップする」機能を 提供するケースを例に、複数BC連携が必要な場合の実装を想定 •

    「Recommendation (レコメンド) 」を中核の業務領域とし、そのために別BCである 「お気に入りリスト」「ユーザープロファイル」の情報を扱う
  10. © dip Corporation. 補足 30 • 粒度が大きいとパフォーマンス悪化につながる • 粒度が小さいと結果整合の制御が増え、設計コストが高くなる •

    物理的な境界はBC(1BCに対しスキーマ群)・1集約1リポジトリ(永続化の単位 は集約) • BCに対してマイクロサービスを適用 ◦ モノレポでBCごとにモジュール化
  11. © dip Corporation. 開発課題と取り組み事例 36 ドメイン駆動設計 ◦ プロジェクトの価値や目的を自分の言葉で再定義し、所属チームレベルに ブレイクダウンした ◦

    企画職の方と日次15分間、理解を深める枠を設けた ◦ 「ドメイン駆動設計をはじめよう」をチーム全員で読むことにし、用語自体の 勉強会を実施 ◦ AWSワークショップ & 社内でのイベントストーミング実施
  12. © dip Corporation. 開発課題と取り組み事例 37 AI活用 ◦ Claude Code での開発

    ◦ 速さを落とさず、基盤的内容変更の共通認識を最短ループで回すことを目的と して以下を構想中 ▪ CLAUDE.md に人もAIも認識しておきたい内容を記載 ▪ Claude Code Actions を使用し、PR作成時に「CLAUDE.mdのルール準 拠チェック」「追記要否判定」を
  13. © dip Corporation. まとめ 40 • AIにより素早い仮説検証が可能となった今だからこそ、ドメインを基にした “本 質的な設計 ”の重要性が高まっている

    ▶ 「共通言語となるモデル」「変更容易性の高いシステム」 • そして、その思想を自然に表現できる言語として Go × DDD の相性の良さ
  14. © dip Corporation. まとめ 41 • AIにより素早い仮説検証が可能となった今だからこそ、ドメインを基にした “本 質的な設計 ”の重要性が高まっている

    ▶ 「共通言語となるモデル」「変更容易性の高いシステム」 • そして、その思想を自然に表現できる言語として Go × DDD の相性の良さ ▶ 「後方互換性の高い言語仕様」「設計の自由度」