34
リソース横断の をしたい
• カスタムエンドポイントを作る
• e.g. /items/{id}/prices [PATCH]
• Spring Data RESTと通常の@Controller(@RestController)はConflictしないので、
エンドポイントの追加は問題ない
• でもこれ、Spring Data RESTのリソース概念と対立する・・・
-> 1つのAPIの中でI/F設計がブレる
36
ビジネスロジックのモデル のモデル
• Spring Data RESTで生えてくるエンドポイントのI/Fは
良くも悪くもDBのデータ構造そのまま
• DBのスキーマ変更=APIのI/F変更
• 「パフォーマンスのためにDB設計変えたい」ってなったとき、
玉突きでビジネスロジックAPIも一緒に変更する必要がある
データ
アクセス
API
DB
ビジネス
ロジック
API
ここを変えたら
こっちも
変えなきゃ
37
ビジネスロジックのモデル のモデル
• 案1. ビジネスロジックAPI側が頑張る
• ビジネスロジックAPI側がDB設計の変更に追従する
• 案2. データアクセスAPI(DB設計)側が譲歩する
• DBのデータ構造を可能な限りビジネスロジック側に合わせる
• パフォーマンスとか冗長性の排除とかは、諦める
データ
アクセス
API
DB
ビジネス
ロジック
API