テーブル設計を遅らせることでユーザー体験の最大化を狙える!?米国式最新開発手法「ADD」とは。。 - Qiita

初めまして、記事に訪問いただきありがとうございますm(_ _)m 今までのプロジェクトでありがちな言い訳。。。 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります なんでこんなことが起こってしまうのか もう15年も前になるPOA vs DOA論争の結果、データ整合性のためにテーブル設計を一番初めに済ませることが一般的になりました。 【初級】ゼロから学ぶDOA 第1回 ですがこのやり方では実際の画面の動きをお客様が見る前に仕様を決めて、 そ

[zentarou]

まだイケハヤネタを使っているようなレベルの人が書いた記事か

[el-condor]

業務上の核心データを格納するテーブルの設計で画面に引きずられてたら、設計変更の柔軟性を失うのも当然では。サマリテーブルなら理解できるけど、その場合は逆に設計変更の工数も大したことないはずで。

[xlc]

あのね。テーブルにせよクラスにせよ「業務」を正しく反映することが重要。この例は画面を見ないと業務が理解できないと言っているに過ぎない。ならば先に画面モックを作ればよろしい。

[tech0403]

顧客の承認が取れればOKって…実装が進むにつれてちゃぶ台返しされるの当たり前だから。BtoCはそもそも確約された要件なんてないし。あと今まで話題にならなかったというのも勉強不足すぎ。MySQLのjoinとか全く関係ないよ

[prograti]

ADDの解釈が自分とは違いますね。こちらの記事の方がしっくりきます。 https://qiita.com/Seiga/items/a59c800e57e022125e3b

[umai_bow]

テーブル設計うんぬんは分からんけど、画面仕様から始めていくのは経験上一番うまくいく

[tenten0213]

この人英語の記事読んだの？全然コンテキストが合っていないように思うんだが…

[BOOOOOOOON]

toBとtoCとでまるで話が違うので銀の弾丸などないのである。toBなら全部門全業務の洗い出し（当事者たちですら忘れていることも含めて）が終わらないことには設計フェーズ入らんし…

[rryu]

API-Driven DevelopmentなのにAPIの話が一切出てこない。MySQLのJOINが遅いというのもいつの時代の話なのかという感じが…

[boomerangj]

データ量が大した事なくて、定期的な停止メンテナンスが許されるならテーブル定義は後からでも何とかなるが、それは全体的に難易度が低いだけだ。幹を知らずに枝葉から決めて問題にならない規模ならどうぞという感じ

[ducktoon]

顧客に恵まれている人は疑問視するかもしれないけど、いくら丁寧に何度もヒアリングしても本当に必要なものを正確に伝えることができない顧客っているんで場合によっては有効な手法だと思う

[lenore]

データ超重要

[ant0720]

画面優先の開発手法だと、バッチ処理だかの画面にない仕様が後から出てきて死ぬ。

[masa_w]

クソみたいなタイトルの記事だと思ったら中身も相応だった

[NOV1975]

こうして一貫性の取りづらいデータ構造が生まれていくのだ

[programmablekinoko]

具体的な話が何もない / テーブル設計が難しいのは、本来多次元構造な現実世界を2次元の表の集まりで表現しなければならないからであって、手法変えても本質的にまとわりつく

[deep_one]

名前つけるほどのこと？

[vuy]

既に書かれてるけど、業務洗い出してBFC作ってないからだろうなぁ。

[xenon_abe]

テーブル設計はどうやったって消耗する

[nanamae]

このタイトルが刺さる層に設計して欲しく無い。あんなけったいなものはできる奴がやればいいのだ。

[for-my-internet-demo]

dddやes見てると、まず最初に基幹RDBがあるというよりはかなり登録イベントや画面に寄った考え方になってて、現実やれんのかなぁみたいな気持ちになるよね。ブコメの反応はわかる

[youichirou]

この話だと、出来上がった画面や遷移がテーブルとかの正規化やCRADがめっちゃやりにくいものにならないか心配。やりたいことが先にまとまってるのは悪いことではないけど。

[lalupin4]

何事だ？

[kanazawawan]

設計能力低いだけじゃねーか。最近、設計だめなやつ増えて現場で苦労するんだわ。画面もjoinも全然別の話。

[vndn]

『実行速度を考慮して画面やユースケースに引きづられたテーブル設計を求められることが減りました。』としたら逆のことが起きる気がするが…。

[kobito19]

他のコメントにもあるけど初期設計から『「テーブル設計」に影響が出るので工数がとてもかかります』とかどうやったらそんなことになるんだ。まずその前提が成立してないんじゃ。

[te2u]

DDD関係なかった。アプリケーションの要であるデータやその周辺の設計にはそれなりに時間がかかる。タイトルのようにそれを軽視するのは怖い。

[shag]

データ肥大化とか、検索遅延とか気にせず全部 DB に突っ込んでいいんだったら設計気にする必要ないよな。

[sisya]

「テーブル設計に影響が出る（お客様がごねすぎて、別の案件に確保した作業期間に突入するので後回しになるため）時間がかかります」

[d346prt]

「やっかみ」の使い方が気になって読み進められない。

[h_taiji]

自然とやってた

[koyancya]

kantomi さん a.k.a SQL おじさんが提唱している「API ファースト開発」っていうやつが、これに近い考え方だった気がする

[findup]

JOIN速度が速くなった、って…レコード数が大量だとJOINテーブル数増えると、やっぱりそれなりに待たされる気がするけど。サーバスペック積んで殴りに行ける前提の話かな。