SUODとは
設計の矛盾をコードに落とし込む前に検品し、頭の中を整理するためのもの。システムへの解像度を高めて、過不足なく設計を揃えていくためのツールです。
| 開発スタイル | SUODの役割 |
|---|---|
| 個人開発 | 自分の頭の中を整理・検品する |
| チーム開発 | メンバーとの共有ツール |
| クライアントあり | 要件確認・説明資料・設計方針の決定ツール |
SUODは以下の4つの図で構成されます。
- S：システム関連図（外部システムとの境界）
- U：ユースケース図（システムがどう振る舞うか）
- O：オブジェクト図（具体的なデータを書き出す）
- D：ドメインモデル図（集約の範囲を含めた設計図）
本プロジェクトでの設計の進め方
基本の順番はU→O→D→シーケンス図ですが、図を書くたびに抜けが見つかり行ったり来たりしました。特にシーケンス図で具体的な処理を追うことで、抽象図の漏れに気づいて戻ることもありました。
SUODは概念整理のツールなので行ったり来たりはある程度仕方ないですが、シーケンス図を書く前に実装イメージを具体的に持っておくことで、ドメインモデルの手戻りを減らせると感じました。
今回Sを省いた理由
システム関連図は外部システムとの境界を整理するときに使います。
今回のシステムはDBとバッチ処理だけで完結していて、外部システムが存在しないので省きました。将来Webサイトなどからのリクエストが絡むようになった段階で、作成しようと思っています。
今回開発するシステム
一言で言うと図書館書籍新着通知システムです。
- 登録した本が登録した図書館の蔵書に追加された瞬間に、メールで自動通知するシステム
- ユーザーは「読みたい本」と「チェックしたい図書館」を事前に登録しておく
- バッチ処理が定期的に蔵書を確認し、「未通知かつ蔵書あり」の時のみ通知を送る
U：ユースケース図
O・D：オブジェクト図とドメインモデル
O：オブジェクト図（具体的なデータのイメージ）
実際にどんなデータが流れるかを具体的な値で表したもの。
D：ドメインモデル図
ドメインは今回はモデル図という形ではなく文章で記載し、それぞれの関係を書き起こし特定しています。
以下の集約に起こしたのちにER図を作成しています。
集約の詳細はこちら
【DDD】リポジトリはテーブル数分作るべき？ 集約の境界線を決める3つの判断ポイント
バッチ処理の設計
抽出条件は enable = true かつ last_notified_at IS NULL。これで無駄なAPIコールもメール送信も発生しない（この設計の詳細は2本目の記事で説明しています）。
処理の流れはシーケンス図にまとめた。
メール送信に使うDTOは CheckNotification のみ。GmailSendService は Book も User も知らなくていい。
@dataclass
class CheckNotification:
book_title: str
user_email: str
status: str
reserve_url: str
参考
- 『ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本』成瀬 允宣
- YouTube: 集約の境界をどうきめるか