ドメイン駆動設計は何を解決する手法なのか - stmn tech blog

こんにちは、リファクタリング大好きなミノ駆動です。 株式会社スタメンでは、企業エンゲージメント構築サービスTUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 ところでDDDはとかく理解しづらく、何のためのDDDなんだという議論になりがちです。この記事では、DDDの真の主人公コアドメインを中心に、DDDが何を解決するものなのか、全体像を改めて整理します。 この記事で扱う内容 DDDが解決したい課題と解決方法の全体像。 この記事では扱わない内容 設計パターンの実例などの実装詳細。 大事な前提 〜利益を得るためのサービス開発 会社でのサービス開発は、趣味や道楽でやるものでしょうか。違いますね。ビジネスとして、企業活動としてサービス開発しています。当たり前の話ですが、利益を得られるように開発しなければなりません。 ドメイン駆動設計は、継

[minodriven]

記事を書きました。「DDDってなんだろう？どう役立つんだろう？」と感じている方にオススメです。

[prjpn]

難しく考えすぎ。変更容易性が9割。動けばいいやのハリボテ開発を無くすためのツール、でいいんだよ。

[hi-hats]

序盤の“DDDが解決したい課題は、大きくは以下2つです” からして独自解釈だよな。意図的に捻じ曲げしてるわけではないと信じたいが。

[phain]

なかなか取り入れるチャンスがない伝説の設計手法という位置付けだわ。

[nakag0711]

この課題の定義だと営利企業以外には適用できないことになるが

[MtAsuka]

DDDってこういう方法論駆動の話ではなく、もっと素朴派オブジェクト指向時代から受け継がれるロマン駆動で取り組んでほしいと思ったり。

[poad1010]

この記事をおすすめしました

[PrivateIntMain]

不必要な面倒さは経営にも給料にもQOLにもよくない。だから必要な面倒さだけ残し（これは0にはならない）、面倒事の原因で切り分け、他に漏れ出さないようにするのが望ましい。その手法の1つでありすべてではない。

[JGEEM]

素晴らしい言語化。なぜコアに集中するのか？を人生に（AC6に）置き換えて表現しているところはお見事。これらを理解せず、モデルを実装に落とすところだけを見ていては視点に欠ける。モデリングこそが重要。

[manaten]

事業のコアドメインが、とか言い出してしまうと開発手法じゃなくてもっと上流のマインドセット的な話になってしまいそう。逆に上流でガチガチにドメイン設計されてたら開発は素直にコーディングできるんだけど

[takahiro665]

例えばgooglekeepはdddを用いるべきか否か。

[findup]

敷居がかなり高くて高尚、というイメージではある。

[Magicant]

DDD が何を解決しようとしてるのかはエヴァンス本の副題にかいてあるよ: 「ソフトウェアの核心にある複雑さに立ち向かう」

[akisei67]

所詮DDDは「設計と実装を近付けるといいよね」という問題解決方法。真に問われるのはビジネスドメインを理解/分解/再構築(AsIs→ToBe)する力=要件や設計の分析や解像度を高める能力。開発手法はメンバーに合わせれば良い

[h_taiji]

保存

[turanukimaru]

コアドメインはユーザを喜ばせる領域（コア＝ユーザ）で、サブドメインはそれを支え代行する（Sub）運営が用意する領域（決済はユーザを代行する。決済だけで喜ぶユーザはいない）。何のための領域か言及しなさすぎ。