テーマ、知りたいこと
DDDは費用対効果に見合っているのか？
背景、状況
新規プロジェクトにてDDDを取り入れて新しいサービスを作ろうとしています。
現状はDDDに慣れるためにサンプルのアプリケーションを作ることになりました。
今は戦略的な設計の段階でBoundedContextは何か？とか集約は何か？とかずっと話し合っています。
そこで疑問に感じたのですが、これらの話し合いが机上の空論のような気がしてなりません。
DDDについて学ぶと確かにそれらしい立派なことが書かれているのですが、開発に協力的な企画者やドメインエキスパートって存在しないと思いますし、実際に手を付ける前にこのContextとこのContextは関係があるとか無いとか言い合いしているのが無駄な時間だと思ってしまいました。
それよりも機能を細かく切り取って部分的に開発を進めて、重複している部分があったら共通化させたりしながらソースコードを整理していくのがいいのではないか？と思いました。(いわゆる軽量DDDにあたるのでしょうか)
そもそも結局フロントエンドとバックエンドで別々に開発をすることになるのに、よくわからない抽象的なContextﾅﾝﾄｶみたいなものについて議論する意味がわかりません。
結局各々が保守運用しやすいようにDDDに則ったアーキテクチャを学んでその通りにコーディングしていくだけじゃ駄目なんでしょうか？
DDDの経験者がいたら、私の見解について意見をしてくれると助かります。
回答5件
#1
総合スコア12268
投稿2025/08/29 04:38
編集2025/08/29 04:39DDDの経験者がいたら
と限定されているところに，条件に合わない者が感想を書くべきではないのでしょうけど……
開発に協力的な企画者やドメインエキスパートって存在しないと思いますし
っていうのは，要するに，そもそもその話の前提条件を満たせないっていうことだったりしないのでしょうか？
要するに，必須要素(?)を欠いているという話なのであれば，「机上の空論」というよりも，それ以前に「無理」ってことなのでは？
（「ナントカ駆動」という話って何なの？ ってググったりするたびに，「いや，そんな話がやれるような恵まれた環境下にあるならば，そんな話に依らなくとも十分まともにやれるってだけなのではなかろうか？」なんて感じてしまう）
#2
総合スコア4348
投稿2025/08/29 05:17
こんにちは。
まず、そもそも DDD が何のためにあるのかを考えた方が良さそうに思いますが、結局 DDD というのは「こうしておいた方が後々良いことになる」っていう先人たちの試行錯誤をまとめ上げたベストプラクティスのようなものです。
つまり、プログラミングをやり続けて「こうした方が良かったな」という気付きを積み重ねていくと、必ず DDD に近づいていくことになります。
コンテキストについて特に疑問があるようなので、軽くイメージを共有すると、
プログラミングではクラス定義などで構成された様々な機能の単位がありますが、使おうとすればどれでも自由に使うことができます。
それって例えると、「料理人」をやってるサービスに意図せず「チェーンソー」を持たせてしまうことがあったりするわけです。
「料理人」には料理に関わる作業をやってもらいたいので、料理に関連するものをまとめて、それ以外を持たせないように、境界を作るのが「良い」ことに気付くわけです。それがコンテキストです。
例えば企業では、部門別にやることできることが異なるはずで、お金の話は経理のコンテキストに、社内 IT システム管理は IT のコンテキストに、それぞれ壁を作って閉じ込める方が「良い」でしょう。IT が会社のお金を自由に触れる状況は「後々良くないことになりそう」な直感がありますね。
という感じで、DDD はコードの重複だとか共通化などの話とは全然違うレイヤの話で、もっともっと上位の概念です。
料理人がチェーンソーを振り回し、トラックを運転し、契約書の精査をし、プログラムを書いても、あなたが良ければそれでいいと思います。
ただし、それには「後々良くないことになりそう」という直感があるのではないでしょうか。
新しいプロジェクトに入ったとき、そのプロジェクトでは料理人は「料理をする担当で、それ以外はしない」となっていた方が、分かりやすいしメンテナンスしやすいのではないでしょうか。
これらの直感をまとめたものが DDD なんです。
ちなみに DDD にはそれを実際に運用する場合の Tips を含んでいて、それがドメインエキスパートとかの話になるんですが、この例で言うとドメインエキスパートは「料理長」とかです。
料理 (ドメイン) のことをよく理解していて、何が必要で何が必要でないかをよく知っている、という人材が必ず1人は存在するので、それらの人材にドメインのことをちゃんと聞きましょう、ってのが DDD の「こうした方が後々良いことになる」というプラクティスの一つなわけです。
最後に、見解について意見を述べると、
各々が保守運用しやすいようにとか言うのはコーディングやサービス単体のレイヤの話で、DDD のレイヤの話をしていません。
DDD はトップダウンなので、DDD を実践する段階でそれがコーディングに影響を及ぼすことはありますが、コーディングのレイヤの話をしていて DDD が実現できることはありません。
#3
回答ありがとうございます。
#1
前提条件が破綻しているというのは一理あります。
そこに無意味さを感じてしまっているのかもしれません。
#2
つまり責任分離のためのアレコレを実際に開発に取り掛かる前にドキュメント化しておこう！って話であっていますか？
今回、私が疑問に感じているのがチーム単位で行うDDDのタイパの悪さです。
私はAndroidアプリを作っているのですが、以前から個人単位でクリーンアーキテクチャを取り入れて開発していました。
なのでチーム単位で話し合ってるとIOSとかバックエンドまで考えないといけなくて、勝手にやっといてくれって思っちゃうんです。
もしかしたら私の環境におけるDDDへの取り組み方がうまくないのかもしれません。
王道的なDDDとは違うのかもしれませんが、BoundedContext、ContextMap、集約といった概念は開発しながら練り上げていったら駄目なのでしょうか？
私のチームでは初めに全部の機能を洗い出して完璧に作ろうとしてしまっていて、それが机上の空論のように感じてしまいます。
それとも始まりはフワフワとした内容の会議になりがちなんでしょうか。
DDDの完成形を想像するとめっちゃいいじゃん！って感じるのですが、その状態に至るまでのアプローチが分からず、モヤモヤしているのかもしれません。
#4
総合スコア4317
投稿2025/08/29 07:25
DDDを試行錯誤しながら開発しています。
いくつか書籍を読んだり実際に手を動かしながらやっていますが、完全に理解した！には全然ならないなぁという感想です。
とにかく難しいという印象です。DDDを自信を持って分かった！と言えない感じ...。
王道的なDDDとは違うのかもしれませんが、BoundedContext、ContextMap、集約といった概念は開発しながら練り上げていったら駄目なのでしょうか？
私はこれに賛成ですね。小さく作り始めて迷ったらその都度DDDとして合ってるか相談しながらやっていくほうがいいと思います。
そもそもDDDは道具だと思うので、DDDとして完璧な設計、実装がゴールではないはず。
新しいサービスをメンテナンスしやすく開発し、できるだけ早くリリースするのがゴールのはず。
でないとお金が稼げないし。
私のチームでは初めに全部の機能を洗い出して完璧に作ろうとしてしまっていて、...
ある程度の洗い出しは必要ですが、最初から完璧に設計をするというのは相当時間がかかるし、何を持って完璧とするのか...。
実際に作り始めたら想定と違ったという事もよくある話ですよね。
仕様変更に強くするためにクリーンアーキテクチャとかDDDの概念があるような気がするのですが...。
#5
総合スコア69
投稿2025/08/29 17:37
前置き
当方"DDDの経験者"ではないので、論点がずれていたり迷惑だったりすればご指摘ください。
回答
DDDは費用対効果に見合っているのか？
DDDは必要だと思うか意見を教えて下さい
うちの会社では動けばよしなので、うちの会社では必要ないかなって感じです。
逆に暗黙的に他のコードと違うような書き方は悪しなので、むしろ不必要を超えて導入してはだめなレベルかもしれません。
が、一人のプログラマーとして。
これがすべてかわかりませんが、少なくとも「特定の権限を持ったユーザーが特定の処理をできるというエンティティ」と「あるプロセスが特定の処理を必要だというインタフェース」ははっきりしておいてくれたらうれしいです。
エンティティははっきりできるのでは
DDDを正直しらなかったのでちょっと調べてみましたが、例えば。
販売部門の注文と会計部門の注文があったとき、同じ注文を呼び出すにしても意味が異なってくるので無理にロジックを共通化すると保守性が下がるからモデル(エンティティ)として定義したいという話だと出てきました。
どう実装するかによらずどの権限を持った人がどんな操作をしたらどうなるかというのはわかりやすく決まっていてほしいので、そういう意味でエンティティは決まっていてほしいといいました。
(しかもそれを直接クラス化できるような気もするし。。。？)
インタフェースははっきりできるのでは
また、逆にこれはDDDの話題とはずれるかもしれませんが、例えば。
販売画面A(販売部門), 販売画面B(販売部門)のように、画面が異なるが内部実装は共通化したいみたいなこともたまにあると思います。
そんな時は(販売=saleだとして)
その販売画面AではIsaleableScreenAのようなインタフェースに依存し、販売画面BではIsaleableScreenBのようなインタフェースに依存するという設計に決めてほしいと思っています。
であれば、saleUseCaseのようなクラスでIsaleableScreenA, IsaleableScreenBを実装すればいいだけですから、同じようにsaleメソッドを要求されるとしても、型安全に共通化できるうえ差し替えも簡単で、何より概念として非常にわかりやすいです。
実際にそういう実装をするかしないかは置いておいて、このようにインタフェースも事前に決めて置けるはずなのではっきりさせておいてほしいです。
余談
機能を細かく切り取って部分的に開発を進めることへの異議
それよりも機能を細かく切り取って部分的に開発を進めて、重複している部分があったら共通化させたりしながらソースコードを整理していくのがいいのではないか？
多分わけわかんなくなってスパゲティ化するんじゃないかと思います。
まずは何のためにDDDを導入するのかをはっきりさせてあなたを含めた全員が納得できないとそういう案も出てきて当然だと思いますよ。
学習コストについて
そもそもオブジェクト指向ですらそれなりに学習コスト高いですからDDDを学ぶのもその感覚に近いんじゃないですかね。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。