開発手法について学んでいると、「DDD（ドメイン駆動設計）」と「SDD（仕様駆動開発）」という言葉を目にすることがあります。
どちらも設計や開発に関する考え方であり、成果物としては似たようなモデルやクラス構成になることも多いため、違いが分かりにくいと感じることがあります。
本記事では、DDDとSDDの違いについて整理します。
仕様とは何か
まずSDDを理解するために、「仕様」について整理します。
仕様とは、
システムが何をするのか、どのように振る舞うのかを定義したもの
です。
例えばECサイトであれば、
- 商品を検索できる
- カートに商品を追加できる
- 注文を確定できる
- 売り切れ商品は購入できない
といった内容が仕様にあたります。
一方で、
- Javaで実装する
- Spring Bootを使用する
- MySQLを使用する
といった内容は仕様ではなく、設計や実装方法です。
SDD（仕様駆動開発）とは
SDD（Specification Driven Development）は、
定義された仕様を中心に開発を進める考え方
です。
一般的な流れは以下のようになります。
要求
↓
仕様
↓
設計
↓
実装
例えば、
要求
「商品を検索できるようにしたい」
↓
仕様
・商品名で検索できる
・部分一致検索を行う
・販売終了商品は表示しない
↓
設計
ProductController
ProductService
ProductRepository
↓
実装
検索APIの作成
という流れになります。
SDDでは、
「何を実現するか」
が中心となります。
DDD（ドメイン駆動設計）とは
DDD（Domain Driven Design）は、
業務そのものを理解し、その業務をモデルとして表現する設計思想
です。
DDDではまず機能や画面を考えるのではなく、
注文とは何か
在庫とは何か
予約とは何か
キャンセルとは何か
といった業務上の概念を整理します。
その結果、
Order
Inventory
Reservation
のようなドメインモデルが生まれます。
その後、
注文登録機能
在庫確認機能
予約キャンセル機能
などの仕様を定義していきます。
DDDの流れを簡略化すると、
業務理解
↓
ドメインモデル
↓
仕様
↓
実装
となります。
DDDとSDDの違い
両者の違いを表にまとめると以下のようになります。
| 項目 | DDD | SDD |
|---|---|---|
| 出発点 | 業務理解 | 要求・仕様 |
| 重視するもの | ドメインモデル | 仕様 |
| 主な問い | 「業務上の意味は何か？」 | 「何を実現するか？」 |
| 開発の流れ | 業務→モデル→仕様→実装 | 要求→仕様→設計→実装 |
なぜ同じように見えるのか
DDDとSDDは成果物だけを見ると似ている場合があります。
例えば、
Product
ProductService
ProductRepository
のような構成は、
DDDでもSDDでも作られる可能性があります。
そのため、
結局同じでは？
と感じることがあります。
しかし実際には、
- DDDは業務を理解するためにモデルを作る
- SDDは仕様を実現するために設計を行う
という違いがあります。
つまり、
成果物ではなく「どこから考え始めるか」が異なります。
DDDは仕様を疑うことがある
SDDでは、
仕様が正しい前提
で開発を進めることが多くなります。
一方DDDでは、
その仕様は本当に業務として正しいのか？
という観点から検討を行います。
例えば、
ユーザーを削除する
という仕様があった場合、
DDDでは
本当に削除するのか？
履歴は残すべきではないか？
という業務上の議論を行うことがあります。
その結果、
削除ではなく退会状態として管理する
というモデルや仕様に変更されることもあります。
実務では組み合わせて使われる
実際のプロジェクトでは、
DDDとSDDは対立するものではありません。
多くの場合、
業務を分析する（DDD）
↓
仕様を定義する
↓
仕様に基づいて開発する（SDD）
という流れになります。
つまり、
DDDによって業務を理解し、
その結果として仕様を定義し、
SDD的に実装を進める
という組み合わせがよく採用されます。
まとめ
DDDとSDDの違いは成果物ではなく、考え方の出発点にあります。
- DDDは「業務上の意味」を中心に考える
- SDDは「仕様」を中心に考える
- DDDは仕様を生み出すための考え方
- SDDは仕様を実現するための進め方
そのため、
「DDDとSDDは似ている」
と感じるのは自然なことであり、実際の開発現場では両者を組み合わせて利用するケースも少なくありません。
重要なのは、
DDDは業務を理解するためのアプローチであり、SDDは仕様を実現するためのアプローチである
という点です。