初めまして、記事に訪問いただきありがとうございますm(_ _)m
今までのプロジェクトでありがちな言い訳。。。
- 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります
- 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります
- 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります
- 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります
- 今からこの仕様変更をすると「テーブル設計」に影響が出るので工数がとてもかかります
なんでこんなことが起こってしまうのか
もう15年も前になるPOA vs DOA論争の結果、データ整合性のためにテーブル設計を一番初めに済ませることが一般的になりました。
【初級】ゼロから学ぶDOA 第1回
ですがこのやり方では実際の画面の動きをお客様が見る前に仕様を決めて、
その仕様に基づいてテーブル設計をしていくため、
テーブル設計を済ませる
-> ビジネスロジックを作る
-> 画面を作っている最中 ←ココ!!
このタイミングで「イメージと違う」「こんなのじゃない」「これじゃ課題を解決できない」
などのやっかみが来て、冒頭の
今からこの仕様変更をするとテーブル設計に影響が出るので工数がとてもかかります
という言い訳が通らなかった日から我々のデスマーチが始まります
被害を最低限に抑えるためにはどうしたらいいのか
すでにおなじみとなった「顧客が本当に必要だった物」
プロジェクトのいかに早い段階で辿り着き、最低限の修正で「本当に必要だった物」に近づけられるか。。。
そのための開発手法が「ADD」という名前でアメリカでも一部で話題になっています。
具体的にADDとはどんな物なのか？
An API-First Development Approach
The Basics of API-Driven Development
DDDアーキテクチャの疎結合性とAPIやDTOの静的データ型を活用することで、
テーブル設計を済ませる
-> ビジネスロジックを作る
-> 画面を作っている最中 ←ココ!!
この順番を逆転し
| フローA | フローB |
|---|---|
| 1. モックデータで画面を作る -> お客様と方向性の確認(承認が取れるまでループ) |
1. 要件定義書からRepositoryのinterfaceとEntityを作る -> お客様と方向性の確認(承認が取れるまでループ) |
| 2. UseCase層を作り結合テスト＆用語集に洗い出されたデータのグルーピング -> お客様と方向性の確認(承認が取れるまでループ) . |
|
| 3. グルーピングされたデータで出尽くした仕様を元にテーブル設計 | |
| 4. Repositoryのinterfaceとデータベース間のSQLクエリを作成 | |
| 4. 納品 | |
というように一番修正コストの高いデータベース実装の順番を最後に持ってくることで、
お客様やプロダクトオーナーと実装者間のイメージの食い違いを最小限の工数で修正することを目指した開発手法になります。
なぜ今まで話題に上がらなかったのか？
私見ですがMySQL8.0が登場してJOINアルゴリズムが高速化したことで、
PostgreSQL、Oracleなどと遜色のないJOIN速度が出るようになり、
実行速度を考慮して画面やユースケースに引きづられたテーブル設計を求められることが減りました。
1つ1つのテーブルに教科書通りの必要最小限のカラム数と拡張性の高い設計を実現できるようになったことで、
「データ整合性と実用性が両立されたテーブル設計」に求められる考慮事項や難易度が下がり、
画面やビジネスロジックなどの、「ユーザー体験に直結する部分」を最優先にできる開発手法がようやく出てきたのかなと思いました。
※2020/10/26追記
記事タイトルと内容が合っていないと指摘をいただいたため、下記の通り記事タイトルを修正させていただきました
まだテーブル設計なんかで消耗してるの!?DDDの次の時代の進化系開発手法「ADD」とは。。
→ テーブル設計を遅らせることでユーザー体験の最大化を狙える!?米国式最新開発手法「ADD」とは。。
お読みいただきありがとうございました
LGTMや拡散をしていただけると泣いて喜びます