質問するログイン新規登録

意見交換

2回答

583閲覧

DDDの「ビジネスロジック」という概念がいまいちピンとこない

pippi3211

総合スコア2

ドメイン駆動設計

ドメイン駆動設計(Domain-driven design, DDD)とは、ソフトウェアの設計手法、および設計思想や哲学のことです。ドメインモデル構築の際に、設計上の判断を決定する枠組みとドメイン設計に関して議論するボキャブラリを提供するものです。

0グッド

0クリップ

投稿2026/02/06 05:55

0

0

テーマ、知りたいこと

ドメイン駆動設計(DDD)に出てくる、「ドメイン層にビジネスロジックを凝縮させる」という話について、皆さんはどう理解されていますか?

書籍や記事を読んで理解したつもりになっても、いざ自分のコードに向き合うと、これはバリデーション?それともビジネスロジック?と、境界線の引き方でいつも迷子になってしまいます。

皆さんの、「ビジネスロジックってこういうことか!」と腑に落ちた時の考え方や例えなどをぜひお伺いしたいです!

背景、状況

最近、AI駆動開発や仕様駆動開発を学んでいるのですが、こうした手法はDDDやアーキテクチャの考え方とすごく相性が良いなと感じています。

AIのアウトプットを「良い実装」に制御するためには、人間側が設計を正しく理解して、指示(プロンプトや定義)に落とし込む必要があるなと実感するようになりました。

ただ、肝心の自分自身が「何がビジネスロジックで、何がそうでないか」を明確に切り分けられていないため、AIへの指示も曖昧になり、結局出てきたコードがイメージと違う……ということが多々あります。

「AIにどう指示するか」というのはまた別途議論の余地があるかなと思いますが、まずは自分のために「ビジネスロジック」の本質について理解したいなと思っています。

周りのエンジニアに聞いたりすると「厳密な正解よりも、チームで『ここに置こう』という納得感があるかどうかが大事」のような意見もあったりしました。
色々な観点で、皆さんの感覚をお聞きできると嬉しいです!

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

回答3

#1

KT001

総合スコア742

投稿2026/02/07 01:33

編集2026/02/07 05:15

直接的な回答ではないのですが、AI駆動開発や仕様駆動開発をする場合、悩むところはAIに任せてみるというのも手かもしれません。

DDDの設計概念は好きな人が多いと思うのですが、海外では主流ではない(知識としては良いが実務では使っていない)ということもあり、おそらく完璧なDDDを実践できている人は少ないと思われます。
https://www.reddit.com/r/ExperiencedDevs/comments/1gpfn6x/if_discord_reddit_twitter_and_uber_dont_use_ddd/

例えば、主要フレームワークの中でSpringはDDDを試しやすいと言われているのですが、それでも純粋なDDDを採用すると破城する(主要な書き方から外れる)ところがあるので、柔軟に設計する必要があります。つまり、DDDの良いところは採用して、フレームワークと合わないところは採用しない(厳密な正解を求めない)柔軟さが必要です。
※ Railsなどは、意図的に非DDDにしているらしく、特定フレームワークとは相性が良くないという問題もあります

DDD自体は元々具体的なコードとは結びついていないので、フレームワークに応じて解釈する必要があるのですが、優秀なAIという部下に任せてしまうというのもアリかと思いました。(人間でもそうなのですが、実装の細かい指示をするよりは、方向性を示した方が上手くいくことが多いです)

ちなみに仕様駆動開発の場合は、方向性を示しつつも(それだけではなく)検証し、各フェーズで振り返りと改善を行うことが重要とされています。
https://developer.microsoft.com/blog/spec-driven-development-spec-kit

#2

この回答は、運営により削除されました。

#3

ymmr

総合スコア103

投稿2026/02/13 10:34

書籍や記事を読んで理解したつもりになっても、いざ自分のコードに向き合うと、これはバリデーション?それともビジネスロジック?と、境界線の引き方でいつも迷子になってしまいます。

場合によりけりです。

DDDはドメイン(=プログラムを適用する領域)におけるプロセスやルールをドメインモデルとして構築することで、ビジネス価値の最大化を目指すアプローチです。

たとえば、teratailの自己紹介文は300文字制限ですが、これがこの300文字制限がUIやDBの制約によるルールであればビジネスルールとは言わないでしょう。一方で、技術的な理由ではなくteratailというサービス上でのルールであれば立派なビジネスルールです。

例として、teratailのプロフィールを作ろうとすると、

  • 項目はユーザー名、表示名、リンク、所属、自己紹介があって、
  • ユーザー名と表示名は必須で、
  • ユーザー名だけは登録後に変更できなくて
  • 自己紹介文は300文字までで
    といったルールが出てきますよね。これをドメイン駆動でモデリングすると
  • プロフィールというEntityはユーザー名、表示名、リンク(optional)、所属(optional)、自己紹介(optional)から成り、
  • ユーザー名は変更ができないというルールがあり、
  • プロフィールはユーザー名と表示名がないものは不正であり、
  • 自己紹介の文字数は301文字以上な不正

みたいな感じでプロフィールのビジネスルールに落とし込めます。ここに技術的な話は出てきません。
質問者さんの疑問が発生するのは、もしかしたらドメイン駆動開発のプロセスとしての順序が違うのかもしれません。

DDD本の中にはドメインモデリングのやり方が書いてあるものもあると思うので、どう進めるとよいのか勉強してみるとよいかもしれません!

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

この意見交換はまだ受付中です。

会員登録して回答してみよう

アカウントをお持ちの方は

関連した質問