実はDDDってしっくりこないんです - タオルケット体操

DDD失敗パターン集 DDDという方法論それ自体に対する僕の立場はあんま好きじゃない寄りのフラット（といいつつほぼ忘れかけている）なんですが、過去何度もDDDでプロジェクトが爆死するのをみたり、爆破してしまったり……というのを見てきたので供養したいとおもいます。 メンバーの大半がDDDを知らない 「えっ!? ドメイン駆動を知らずにDDDを?」 「出来らぁっ!」 DDDを知らずにDDDをする、という前提がすでに禅問答じみてる気がしますが、たぶん一番よく見かける失敗パターンなんじゃあないでしょうか。 どういうことかというと、オニオンとかレイヤードとかクリーンなアーキテクチャのモジュールの命名ルールと構造を採用（採用できているとは言っていない）しただけの状態です。 私見ですが、アーキテクチャというのはメンバー全員がそれを理解できていない限り*1即破綻します。 理解できない人はどこに処理を書いてい

[pptppc2]

空の境界、月姫やFateと違って、奈須きのこ著でも型月作品って言われても確かにしっくり来ないかもしれないな。

[turanukimaru]

最近気が付いたのだが、関心領域を業務にするべきところ、対象業務をドメインにしてるDDD論者がほとんど。なのでドメイン≠関心領域になってる。多分DDD論者全員勘違いしてる。100字じゃ足りないなコメント行くかな…

[programmablekinoko]

まあプレゼン層とDB層とビジネスロジック層は分けた方がいい、あとよくすり合わせしとけよ、くらいじゃないかな

[atsushifx]

「実はオブジェクト指向ってしっくりこないんです！」という記事が昔あって非難囂々だったが、こっちは首肯しかなかった。DDDって、やっぱり難しいよね。やるべきだとは思うけど

[chinpokomon_master]

まず普通にプログラミングしろよっていつも思うわ。

[boomerangj]

設計パターンよりも開発者しかDDDの価値に賛同してない自己満パターンも失敗要因になりがちだと思うなあ。ユビキタス言語を作っても、お付き合いでやってる方は"まあそれで良いんじゃないですか"で済ませてしまうやつ

[NOV1975]

これに限らず、「べき論系」の開発手法って要件レベルで完全にコントロール可能な案件を話を完全に理解できるエンジニアだけで実行しないと理想と現実のギャップがすごいってなりがち。ノリで採用してはならない

[Magicant]

その「ただの常識」を達成することが全く容易ではないから DDD が求められるのであり / 「しっくりこない」のはその難しさを理解できてないから / なんちゃってで開発してないで本気で難しさにぶつかってみろよ

[peketamin]

“かのリーナスもまずデータの設計をしっかりやれ、アルゴリズムをごちゃごちゃ弄るのは雑魚！！！って言ってた気がします。”

[cpw]

DDDをやろうとするとこれはドメインだドメインじゃないとか考え方の違いでてきて対して効果がないところの議論が増える。複数人で開発するならどこに何を書くか明確になるレイヤー分けくらいが良いと考えてる。

[takatama]

書籍Patterns, Principles, and Practices of Domain-Driven Designだと冒頭150ページを使って「DDDはコスト高いからな！引き返すなら今だぞ！CRUDでもTransaction Scriptでもいいんだぞ！」って何度も念を押してから、DDDでの設計論がはじまる

[motchang]

"それぞれ一概念と一モジュールが常に対応するという思い込みは危険です。" / "開発と設計と仮説検証がイコールで結ばれているような極限環境でDDDするのはたぶん時間の無駄です。"　/ 同意で首もげそう

[ledsun]

僕には、DDDは難しい話を経由して最終的に「Tell, Don't Askレベルの愚直なOOPしようぜ」って言っているように聞こえる。

[katzchang]

“この本ややこしすんぎ” これはそう思います

[ngsw]

この手の話を読んだり聞いたりするといつもを Rui Ueyama さんのエントリを思い出す https://note.com/ruiu/n/n9948f0cc3ed3

[kat21]

難解だし習得に時間がかかるのは同意。だからこそ、ドメインの表現を強制できる言語ならやりやすい(逆に言えば Ruby などでは扱いにくい)

[taguch1]

ぶっちゃけていうと筆者はオレオレDDD実現系アーキテクチャが嫌いなだけなのかもしれません。

[ssids]

自分が勝手に思ってるだけだけど、ドメイン駆動の後継が NoCode や RPA だったりするのかな、と

[findup]

とにかく設計も実装もシンプルに読みやすく、でええやんって思う。

[ysksy]

2007年全3巻完結予定の話はやめてくれ。未だに3巻待ってるんだよ。

[unakowa]

うん。しっくりこない。トップブコメは非建設的ではないかな？

[Error401]

TDDもそうなんだけど、”driven”が日本人として腹落ちし難い単語なのではと思う。一応「駆動」と訳されてるけど・・・

[Dursan]

昔の作品とはいえヨコヲタロウの作品だしな、ドラッグオンドラグーン。あ、DODじゃない、、、、

[IZqCqpA629KuL1]

今は知らないけど昔見かけたDDD界隈はマサカリ投げまくりの初心者お断り感の強いコミュニティな印象で苦手だったな。DDDがなかなか浸透しないのは質問し辛い文化にも一因があると思ってる。

[otihateten3510]

最終的にこういう設計パターンに出てくる用語は混乱するので使わなくなるんだよなー、全部嫌いだ。作るなら曖昧性を完全に排除しろ。

[Nyoho]

“メンバー全員がそれを理解できていない限り即破綻します。理解できない人はどこに処理を書いていいのかわからず永遠にレビューでリジェクトされ続けるか、コピペでコードを増やすしかないからです。”

[shikiarai]

Deadline Driven Design

[takezaki]

“どれも有識者から「ドメインから駆動してへんだけやん」と一蹴されそうな雰囲気になっているわけなんですが、DDDが難解すぎること、そして適用するべきじゃない領域のサービス開発で用いられてしまっているという”

[for-my-internet-demo]

サーバーサイド長くてもMySQL出し入れおじさん以上のキャパ持った人も言うほど多くないし大概それで充分なのでそんなもんという気もする

[hackpopo]

DDDの最大の弱点はスモールスタートが難しい点かな。一部導入してもそこの学習コストが高くなるだけだし、一部の人がやってもあんまり意味ない。ボトムアップじゃなくてトップダウンで導入を決めるもの

[MtAsuka]

DDDは古き良き素朴派オブジェクト指向の時代の集大成的なものなので、今あれを絶対的な正義としてそのまま取り入れるのは危険だよね。オブジェクト指向は教典に従うのではなく自分でうまく取捨選択できないと難しい。

[svapna]

“CQRS”

[darjeeling_2nd]

遊戯王に出てきたドラゴン・ダイス＆ダンジョンズがなんだって？

[t_motooka]

Enterprise FizzBuzz、良い例え。

[mattn]

わかる(とても)

[t-wada]

"DDD失敗パターン集 1.メンバーの大半がDDDを知らない 2.CRUDの延長線上にあるBetter MVC止まり 3.Javaの原典を直訳しがち 4.ただのディレクトリとファイル名ルールとしての採用されたアーキテクチャ" わかりみが深い

[gochisoukedoru]

最新刊2007年だもんな...もう古典だもの

[n314]

雑にやってみたあとに固めにやってみて、しっくりこなかった。enterprise fizzbuzz感は分かる。DDDが本当に必要な人達から見たら、自分の扱ってるものはfizzbuzzぐらいの複雑さってことなのかも。

[onesplat]

ぶっちゃけエリックエヴァンス界隈の飯の種にされてるだけでしょ。知識として知っておいて損は無いが「DDDやったるで〜！」みたいに手段が目的化すると100%失敗する。必要に応じてネーミングだけ取り入れるくらいで十