テーマ、知りたいこと
DDDは費用対効果に見合っているのか？
背景、状況
新規プロジェクトにてDDDを取り入れて新しいサービスを作ろうとしています。
現状はDDDに慣れるためにサンプルのアプリケーションを作ることになりました。
今は戦略的な設計の段階でBoundedContextは何か？とか集約は何か？とかずっと話し合っています。
そこで疑問に感じたのですが、これらの話し合いが机上の空論のような気がしてなりません。
DDDについて学ぶと確かにそれらしい立派なことが書かれているのですが、開発に協力的な企画者やドメインエキスパートって存在しないと思いますし、実際に手を付ける前にこのContextとこのContextは関係があるとか無いとか言い合いしているのが無駄な時間だと思ってしまいました。
それよりも機能を細かく切り取って部分的に開発を進めて、重複している部分があったら共通化させたりしながらソースコードを整理していくのがいいのではないか？と思いました。(いわゆる軽量DDDにあたるのでしょうか)
そもそも結局フロントエンドとバックエンドで別々に開発をすることになるのに、よくわからない抽象的なContextﾅﾝﾄｶみたいなものについて議論する意味がわかりません。
結局各々が保守運用しやすいようにDDDに則ったアーキテクチャを学んでその通りにコーディングしていくだけじゃ駄目なんでしょうか？
DDDの経験者がいたら、私の見解について意見をしてくれると助かります。
回答8件
#1
総合スコア12291
投稿2025/08/29 04:38
編集2025/08/29 04:39DDDの経験者がいたら
と限定されているところに，条件に合わない者が感想を書くべきではないのでしょうけど……
開発に協力的な企画者やドメインエキスパートって存在しないと思いますし
っていうのは，要するに，そもそもその話の前提条件を満たせないっていうことだったりしないのでしょうか？
要するに，必須要素(?)を欠いているという話なのであれば，「机上の空論」というよりも，それ以前に「無理」ってことなのでは？
（「ナントカ駆動」という話って何なの？ ってググったりするたびに，「いや，そんな話がやれるような恵まれた環境下にあるならば，そんな話に依らなくとも十分まともにやれるってだけなのではなかろうか？」なんて感じてしまう）
#2
総合スコア4370
投稿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
総合スコア4319
投稿2025/08/29 07:25
DDDを試行錯誤しながら開発しています。
いくつか書籍を読んだり実際に手を動かしながらやっていますが、完全に理解した！には全然ならないなぁという感想です。
とにかく難しいという印象です。DDDを自信を持って分かった！と言えない感じ...。
王道的なDDDとは違うのかもしれませんが、BoundedContext、ContextMap、集約といった概念は開発しながら練り上げていったら駄目なのでしょうか？
私はこれに賛成ですね。小さく作り始めて迷ったらその都度DDDとして合ってるか相談しながらやっていくほうがいいと思います。
そもそもDDDは道具だと思うので、DDDとして完璧な設計、実装がゴールではないはず。
新しいサービスをメンテナンスしやすく開発し、できるだけ早くリリースするのがゴールのはず。
でないとお金が稼げないし。
私のチームでは初めに全部の機能を洗い出して完璧に作ろうとしてしまっていて、...
ある程度の洗い出しは必要ですが、最初から完璧に設計をするというのは相当時間がかかるし、何を持って完璧とするのか...。
実際に作り始めたら想定と違ったという事もよくある話ですよね。
仕様変更に強くするためにクリーンアーキテクチャとかDDDの概念があるような気がするのですが...。
#5
総合スコア101
投稿2025/08/29 17:37
前置き
当方"DDDの経験者"ではないので、論点がずれていたり迷惑だったりすればご指摘ください。
回答
DDDは費用対効果に見合っているのか？
DDDは必要だと思うか意見を教えて下さい
うちの会社では動けばよしなので、うちの会社では必要ないかなって感じです。
逆に暗黙的に他のコードと違うような書き方は悪しなので、むしろ不必要を超えて導入してはだめなレベルかもしれません。
が、一人のプログラマーとして。
これがすべてかわかりませんが、少なくとも「特定の権限を持ったユーザーが特定の処理をできるというエンティティ」と「あるプロセスが特定の処理を必要だというインタフェース」ははっきりしておいてくれたらうれしいです。
エンティティははっきりできるのでは
DDDを正直しらなかったのでちょっと調べてみましたが、例えば。
販売部門の注文と会計部門の注文があったとき、同じ注文を呼び出すにしても意味が異なってくるので無理にロジックを共通化すると保守性が下がるからモデル(エンティティ)として定義したいという話だと出てきました。
どう実装するかによらずどの権限を持った人がどんな操作をしたらどうなるかというのはわかりやすく決まっていてほしいので、そういう意味でエンティティは決まっていてほしいといいました。
(しかもそれを直接クラス化できるような気もするし。。。？)
インタフェースははっきりできるのでは
また、逆にこれはDDDの話題とはずれるかもしれませんが、例えば。
販売画面A(販売部門), 販売画面B(販売部門)のように、画面が異なるが内部実装は共通化したいみたいなこともたまにあると思います。
そんな時は(販売=saleだとして)
その販売画面AではIsaleableScreenAのようなインタフェースに依存し、販売画面BではIsaleableScreenBのようなインタフェースに依存するという設計に決めてほしいと思っています。
であれば、saleUseCaseのようなクラスでIsaleableScreenA, IsaleableScreenBを実装すればいいだけですから、同じようにsaleメソッドを要求されるとしても、型安全に共通化できるうえ差し替えも簡単で、何より概念として非常にわかりやすいです。
実際にそういう実装をするかしないかは置いておいて、このようにインタフェースも事前に決めて置けるはずなのではっきりさせておいてほしいです。
余談
機能を細かく切り取って部分的に開発を進めることへの異議
それよりも機能を細かく切り取って部分的に開発を進めて、重複している部分があったら共通化させたりしながらソースコードを整理していくのがいいのではないか？
多分わけわかんなくなってスパゲティ化するんじゃないかと思います。
まずは何のためにDDDを導入するのかをはっきりさせてあなたを含めた全員が納得できないとそういう案も出てきて当然だと思いますよ。
学習コストについて
そもそもオブジェクト指向ですらそれなりに学習コスト高いですからDDDを学ぶのもその感覚に近いんじゃないですかね。
#6
総合スコア4370
投稿2025/09/01 00:26
ドキュメント化は重要なタスクですが、別にドキュメント化が DDD というわけではないと思います。
チーム単位で話し合ってるとIOSとかバックエンドまで考えないといけなくて、勝手にやっといてくれって思っちゃうんです。
DDD を適用するレイヤ (上位) での議論では、あらゆるサービスを横断して同じ思想で設計を行うことを強制するために整合性を保つ圧力が必要ですが、DDD が適用された後の各サービスのレイヤでは、むしろ他のサービスは壁 (コンテキスト) の外にあるので考えなくても良い方向になっているはずです。
すなわち「勝手にやっといてくれ」って思うのは、あなたが Android コンテキスト内の開発者の立場なら正しくて、DDD の導入担当者の立場なら間違いです。
DDD の導入が既にできている環境では、個別のコンテキストの中で開発するにあたって自分が内部的に用いるモデルと連携先のコンテキストとの共通モデルの定義だけで話が済むので、むしろ外の影響を受ける機会が減ります。
あらゆるコンテキストを横断して「ちゃんと DDD に則った形にしましょう」を議論する段階なら、iOS やバックエンドにも「ちゃんと DDD させる」という圧力を掛ける必要があるわけです。
私のチームでは初めに全部の機能を洗い出して完璧に作ろうとしてしまっていて、それが机上の空論のように感じてしまいます。
これは DDD では別に必須ではないですね。
DDD をやるにあたって必要なのは「常に DDD のルールに則って設計を進める」という前提だけで、全部の機能を洗い出すなどは別に DDD は関係ないです。
全部の機能を洗い出す、もちろんできるって言うならやった方がいいですけど、一般の状況ではできるわけがないので、机上の空論に感じるというのはその通りだと思います。
DDD のルールから外れないことだけ意識して、あとは開発しながら調整していけば良いと思います。
とりあえず Bounded Context の存在を意識する、というよりコンテキストを乗り越えるようなコードを書かない・書かせないことだけ意識していれば他の概念の段階的導入も可能だと思います。
#7
週末もDDDに関する本を読んだりして自分なりに考えてみた結果、何人かの回答にもあった結局開発しながら調整していくのが良いのでないかという結論に至りました。
会議がずっと雲を掴むような感覚なのはDDDという理想ばかり意識して、実際にコーディングする意識を持っていない人が過半数だったからだと思います。
(「BoundedContextが大事らしい！とりあえずやってみよう！なんで必要なのかはよく分からんけど。」みたいな感じです。)
一旦会議も落ち着いて、各々DDDのアーキテクチャについて勉強しながら一旦コーディングしてみるか。という段階に落ち着きました。
やっぱり、DDDって難しいですね。
本に書いてあるとおりルールを守ってコーディングしても、効果を感じるのはもう少し後だと思いますし。。。
（コーディング中も責任分離はできているので、頭の中で整理はしやすいというメリットはありましたが。）
DDDの会議が気に食わなすぎて愚痴のような形で意見交換を開いてしまったのですが、皆さんの意見を聞けて助かりました。
ありがとうございました。
#8
総合スコア139
投稿2025/09/21 03:42
DDD的なプロジェクト構成は必要不可欠で、出来ないとまともな保守管理も出来ない気がします。
ドメインって日本語的には階層構造のことなので、そういう意識がない時点で今の時代、既に現代的ではないです。
デザインパターンはその枠組みみたいな。
エンティティとかはそこまで考えなかったけど、valueobjectとかは普通に役立ちますね。基礎の延長みたいなものだし
ピーコックアンダーソンのDDD動画講座をやりましたが、死ぬほど時間掛かりました。動画でプログラミングの勉強なんてするもんじゃないです。
objectの真正性の検証とか無駄にややこしいけど、業務なら要るんじゃないのか多分。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。