1.
を利用した
の設計と、作り直しまでの道のり
Isao Takahashi
楽天株式会社 トラベルサービス開発・運用部
2017-11-24, Spring Fest 2017

2.
2
1. Spring Data RESTの紹介
2. 実際のプロジェクトに適用してみよう
1. Spring Data RESTを使ってみる
2. Spring Data RESTを使ってみた結果
3. Spring Data RESTは使えるのか?
4. まとめ

3.
3
自己紹介
高橋 勲
兼
コード書くこと全般
機能実装
リファクタリング
自動化

4.
4
皆さん、
使ってますか？

5.
5
皆さん、
使ってますか？

6.
6

7.
7
分で が作れる

8.
8

9.
9
分で が作れた

10.
10
の特徴
• と を定義したら が生える
• 自前でロジックを書く必要が皆無
• 全部生える
• 「特定の を公開しない」という設定もできるので安全
• の処理をよしなにやってくれる
• 統一された フォーマット で
やってくれる
• ページングとかも超簡単

11.
11
いい感じ

12.
12
実際のプロジェクトで
使える

13.
13
今回のお題アーキテクチャ
UI
UI
ビジネス
ロジック
API
DB
DB
データ
アクセス
API
ビジネス
ロジック
API データ
アクセス
API
データ
アクセス
API
DB
FrontEndと
BackEndを
分離
ビジネスロジックと
データを
分離
1つのデータにつき
1つのアプリケーション
のみアクセス可能

14.
14
今回のお題アーキテクチャ
• いっぱい 作る
• データ層側は基本的にはシンプルな のみ
• 中間層 ビジネスロジック から
複数のデータ層 データアクセス にアクセスする
• データアクセス 同士は が揃っていてくれるととてもうれしい
• 規約
• のフォーマット
•

15.
15
の特徴 再掲
• と を定義したら が生える
• 自前でロジックを書く必要が皆無
• 全部生える
• 「特定の を公開しない」という設定もできるので安全
• の処理をよしなにやってくれる
• 統一された フォーマット で
やってくれる
• ページングとかも超簡単

16.
16
今回のお題アーキテクチャ
UI
UI
ビジネス
ロジック
API
DB
DB
データ
アクセス
API
ビジネス
ロジック
API データ
アクセス
API
データ
アクセス
API
DB

17.
17
今回のお題アーキテクチャ
データ
アクセス
API
DB
シンプルな
CRUD操作だけ
提供する

18.
18
向いているのでは

19.
19
やってみよう

20.
20
お題データ構造
• お店(Shop)データ
• 店名、フロア数を持つ
• 複数の商品を販売できる
• 商品(Item)データ
• 名前を持つ
• 複数の料金設定を持つ
• 料金設定(Price)データ
• 「商品を何個買うといくらになるか」の
料金データを持つ
• いわゆる『まとめ買い』価格を表現できる
= ¥190
= ¥100
= ¥150

21.
21
データの階層構造は、こんな感じ
2個で¥190
駄菓子屋
1階建て
チョコ
飴
1個 ¥150
2個 ¥190
1個 ¥100

22.
22
のクラスにすると、こう
public class Shop {
private String name;
private int floor;
private List<Item> items;
}
public class Item {
private String name;
private List<Price> prices;
}
public class Price {
private int unit;
private BigDecimal amount;
}
2個で¥190
駄菓子屋
1階建て
チョコ
飴
1個 ¥150
2個 ¥190
1個 ¥100

23.
23
やりたいこと
• ShopのCRUD
• 「Shopが販売するItem」のCRUD
• 「ItemごとのPrice」のCRUD

24.
24
で実装すると･･･
• ShopのCRUD
• /shops [POST/GET]
• /shops/{id} [GET/PUT/PATCH/DELETE]
• 「Shopが販売するItem」のCRUD?
• /items [POST/GET]
• /items/{id} [GET/PUT/PATCH/DELETE]
• 「ItemごとのPrice」のCRUD?
• /prices [POST/GET]
• /prices/{id} [GET/PUT/PATCH/DELETE]

25.
25
ん？
何か思ってたのと違う…

26.
26
こんな感じを期待していた
• ShopのCRUD
• /shops [POST/GET]
• /shops/{id} [GET/PUT/PATCH/DELETE]
• 「Shopが販売するItem」のCRUD
• /shops/{id}/items [POST/GET]
• /shops/{id}/items/{id} [GET/PUT/PATCH/DELETE]
• 「ItemごとのPrice」のCRUD
• /shops/{id}/items/{id}/prices [POST/GET]
• /shops/{id}/items/{id}/prices/{id} [GET/PUT/PATCH/DELETE]
URLから
階層構造が
読み取れる

27.
27
で 生えてくる たち
• 全部がトップレベルリソース
• リソース同士はrelationのリソース(/A/{id}/B/{id})で繋がる
• そこには上位下位の関係性はない
• ちょっとそれは「頭の中の階層構造」と違う･･･
Shop Item Price
Shop
Item
Price
Data REST上の構造
頭の中の構造

28.
28
他の問題も出てきた

29.
29
リソース横断の
をしたい

30.
30
やりたいこと
• ShopのCRUD
• 「Shopが販売するItem」のCRUD
• 「ItemごとのPrice」のCRUD
• 「あるItem内のPrice全部」をまとめて更新したい

31.
31
リソース横断の をしたい
• 「あるItem内のPrice全部」= 複数のリソースをいっぺんに更新したい
商品 個数 価格
チョコレート 1 150
飴 1 100
飴 2 190

32.
32
リソース横断の をしたい
• 「あるItem内のPrice全部」= 複数のリソースをいっぺんに更新したい
• 生えてくるエンドポイントは1つずつしか操作できない
商品 個数 価格
チョコレート 1 150
飴 1 100
飴 2 190

33.
33
リソース横断の をしたい
• 「あるItem内のPrice全部」= 複数のリソースをいっぺんに更新したい
• 生えてくるエンドポイントは1つずつしか操作できない
• 「1つずつAPI callすればいいじゃん」 -> トランザクション管理の問題が発生
商品 個数 価格
チョコレート 1 150
飴 1 100
飴 2 190

34.
34
リソース横断の をしたい
• カスタムエンドポイントを作る
• e.g. /items/{id}/prices [PATCH]
• Spring Data RESTと通常の@Controller(@RestController)はConflictしないので、
エンドポイントの追加は問題ない
• でもこれ、Spring Data RESTのリソース概念と対立する･･･
-> 1つのAPIの中でI/F設計がブレる

35.
35
ビジネスロジックのモデル
側のモデル

36.
36
ビジネスロジックのモデル のモデル
• Spring Data RESTで生えてくるエンドポイントのI/Fは
良くも悪くもDBのデータ構造そのまま
• DBのスキーマ変更＝APIのI/F変更
• 「パフォーマンスのためにDB設計変えたい」ってなったとき、
玉突きでビジネスロジックAPIも一緒に変更する必要がある
データ
アクセス
API
DB
ビジネス
ロジック
API
ここを変えたら
こっちも
変えなきゃ

37.
37
ビジネスロジックのモデル のモデル
• 案1. ビジネスロジックAPI側が頑張る
• ビジネスロジックAPI側がDB設計の変更に追従する
• 案2. データアクセスAPI(DB設計)側が譲歩する
• DBのデータ構造を可能な限りビジネスロジック側に合わせる
• パフォーマンスとか冗長性の排除とかは、諦める
データ
アクセス
API
DB
ビジネス
ロジック
API

38.
38
ん～･･･
一度立ち止まって考えてみる

39.
39
今回のお題アーキテクチャ
データ
アクセス
API
DB
シンプルな
CRUD操作だけ
提供する

40.
40
シンプルじゃない
操作がしたくなった

41.
41
今回のお題アーキテクチャ
ビジネス
ロジック
API
データ
アクセス
API
DB
ビジネスロジックと
データを分離

42.
42
ビジネスロジックと
データが分離できてない

43.
43
ダメじゃん

44.
44
アーキテクチャの再考
• いくつかの役割・機能をデータアクセスAPIに持たせる
• 「ロジックと実データ構造の差異を吸収する」役割
• 「リソースまとめて更新」機能

45.
45
となると、
向いてないのでは

46.
46
との別れ
• 得たもの
• 自由
• 失ったもの
• 時間
• 「Spring Data RESTがこうなってるから、○○はできない」
という言い訳

47.
47
が我々にもたらしていたもの
• (良くも悪くも)制約
• 良いところ
• 実装すべきコードがとても少ない
• 制約により選択肢が狭まる → 迷わない
• イマイチだったところ
• 制約が強い
→ その周辺の設計(DB、ビジネスロジックAPI)に強く影響してしまう

48.
48
は
使えないコなの

49.
49
は使えないコなの
• やりたいこととSpring Data REST Wayが合致すれば強い
• 実際に使ってみたことで、合うもの/合わないものがはっきりと分かった
• ちなみに、楽天トラベルの別プロジェクトでは絶賛本番稼働中
• 無理やり使おうとするのがダメだった
• あえて制約を強くしているものに対して、抜け道を探しまくるのは良い手ではない

50.
50
まとめ
• Spring Data RESTで簡単にRESTful APIを作れる
• 用法用量を守って使いましょう
• Spring Data RESTが輝ける場所で採用しましょう
• たくさんの階層構造を持たないデータ
• 「リソースごとの単純なCRUDしかしない」ようなデータ

51.
51
引用文献
GitHub
•https://github.com/logos
Qiita
•http://help.qiita.com/ja/articles/others-brand-guideline
いらすとや
•http://www.irasutoya.com/p/terms.html
フリー素材 ピクトグラム
•https://free-pictograms.com/
Spring Data REST
•https://projects.spring.io/spring-data-rest/
•Accessed on 2017-11-21