Datastore/Go のデータ設計と struct の振る舞いについて

Datastore/Go のデータ設計と
struct の振る舞いについて

自己紹介
twitter : pospome
blog ：pospomeのプログラミング日記
職種 : サーバサイドエンジニア
興味　 : クラス設計全般, DDD
アイコン：羊じゃなくてポメラニアン
その他　：「ポメ」って呼んでください。

今日の発表の結論を言うと
Datastoreのデータ構造の設計やレビューでは
Kindに持たせる値だけではなく、
値が持つ振る舞いと特性も一緒に考えた方がいい

ソーシャルゲームのユーザー情報を表現する User Kind を
例に説明します

ID TEL Email
Profile
Image
Profile
Movie
HP ATK DEF
1 000 x x.png 100 100 100
2 111 y y.mp4 50 50 50
3 222 z z.png 200 200 200

RDBで考えるとこの構造で問題ないかもしれないが
Datastore で適切とは限らない
Datastore のデータ構造をマッピングした struct の
振る舞いを通して考えてみる

例1
ProfileImage と ProfileMovie は
どちらか一方しか登録できない
という仕様を表現する

type User struct {
//他のフィールドは省略
ProfileImage, ProfileMovie string
}
それぞれが単なるフィールドだと
「Image, Movie どちらか一方を登録する」
という仕様を表現するのは難しい

これを修正すると・・・

type User struct {
Profile Profile
}
type Profile struct {
Image, Movie string
}
func NewImageProfile(image string) Profile {
return Profile{
Image: image,
}
}
func NewMovieProfile(movie string) Profile {
return Profile{
Movie: movie,
}
}
「Image, Movie どちらか一方を登録する」
というルールを Profile 自体に持たせることで
仕様を表現することができる

ID TEL Email
Profile.
Image
Profile.
Movie
HP ATK DEF
1 000 x x.png 100 100 100
2 111 y y.mp4 50 50 50
3 222 z z.png 200 200 200

例2
Email, TEL は
OAuth Scope = Contact でしか取得できない

type User struct {
TEL, Email string
}
func Get(scope string) User {
var u User = GetUserFromDB()
if scope != "Contact" {
u.TEL = ""
u.Email = ""
}
return u
}
ロジック上で Contact scope = Email, TEL を表現している

type User struct {
Contact Contact
}
type Contact struct {
TEL, Email string
}
func Get(scope string) User {
var u User = GetUserFromDB()
if scope != "Contact" {
u.Contact = nil
}
return u
}
Scope が扱う Contact という概念は
具体的に TEL, Email を含む
抽象度の違う値同士を扱おうとすると、
ロジックが複雑になる可能性がある
TEL, Email という具体的な概念を
Scope の Contact という抽象度に合わせる
Scope と struct が一致しているので、
直感的に理解しやすい
Contact の持つ値が変化しても、
u.Contact = nil に修正は発生しない
これはロジックが Contact という抽象度の概念
を扱っているからであって、
t.TEL = “” のように抽象度がマッチしない場合
に比べると変更に強くなる

ID
Contact
.TEL
Contact
.Email
Profile.
Image
Profile.
Movie
HP ATK DEF
1 000 x x.png 100 100 100
2 111 y y.mp4 50 50 50
3 222 z z.png 200 200 200

例3
ATK, DEF は HP の値によって増減する

type User struct {
HP, ATK, DEF int
}
func (u *User) GetAtk() int {
//HPに依存する
return u.ATK * u.HP
}
func (u *User) GetDef() int {
if u.HP < 100 {
//ピンチになると強くなる
return u.DEF * 2
}
return u.DEF
}
それぞれの値を算出するロジックは
HP, ATK, DEF に依存しているが、
他の値には依存していない

type User struct {
Battle Battle
}
type Battle struct {
HP, ATK, DEF int
}
func (b *Battle) GetAtk() int {
//HPに依存する
return b.ATK * b.HP
}
func (b *Battle) GetDef() int {
if b.HP < 100 {
//ピンチになると強くなる
return b.DEF * 2
}
return b.DEF
}
HP, ATK, DEF を Battle として定義
「対戦」に関するロジックは
Battle に集中させる
User は「対戦」以外のロジックに集中できる
対戦のロジックはゲームのコアな要素なので、
複雑な仕様になりやすい
User から分離しておくと
Battle に interface を持たせて
特定のロジックを抽象化させたり、
固定値を設定した Battle に差し替えるなど、
User を汚さずに「対戦」を表現できる

ID
Contact
.TEL
Contact
.Email
Profile.
Image
Profile.
Movie
Battle.
HP
Battle.A
TK
Battle.
DEF
1 000 x x.png 100 100 100
2 111 y y.mp4 50 50 50
3 222 z z.png 200 200 200

ということで、最終的に・・・

type User struct {
ID int64
Contact Contact
Profile Profile
Battle Battle
}
type Contact struct {
TEL, Email string
}
type Profile struct {
Image, Movie string
}
type Battle struct {
HP, ATK, DEF int
}
振る舞いを考慮すると User struct は以下になる

ID
Contact
.TEL
Contact
.Email
Profile.
Image
Profile.
Movie
Battle.
HP
Battle.A
TK
Battle.
DEF
1 000 x x.png 100 100 100
2 111 y y.mp4 50 50 50
3 222 z z.png 200 200 200
User struct を保存する User Kind は以下になるので、
最初のデータ構造とは違うものになった

Datastoreのデータ構造の設計やレビューでは
Kindに持たせる値だけではなく、
値が持つ振る舞いと特性も一緒に考えた方がいい

RDBだと struct の構造を
そのまま保存するものではないので
必要に応じてORMや手動マッピングロジックで
永続化データとモデルをマッピングする
struct の振る舞いを考慮してテーブル構造を
考える必要性は低い
永続化データとしての正しさを考えればいい
RDBはSQLによる柔軟なクエリが可能なので、
無理やり struct を保存する工夫をするよりも
永続化データとしての正しさを重視した方がいい

Datastore は struct をそのまま保存できるので、
データ設計の段階で struct を考慮して設計すると
手戻りが少なく、
自分でインピーダンスミスマッチを解消する必要もない
極端に言うと
Datastore設計 = モデル設計
ただし、
Datastore に保存できないデータ構造もあるので注意

Kind のプロパティ名に Prefix がある場合は
その値は関連性の高い値である可能性が高い
関連性の高い値は
それ独自の振る舞いや特性を持つ可能性が高い
そういった関連性の高いデータに対して
仕様を表現するロジックを紐付けることによって、
責務が明確になる

今回の例は説明用ということもあって、
結構無理矢理なケースかと思います
今回の例であれば
Datastore のプロパティを
フラットに並べても問題ないかもしれません
ここはモデルの設計方針によって変わります
重要なのは
「struct の振る舞いも考慮する」
という選択肢を持つことです

Datastore の設計をする際には
struct の振る舞いも考慮してみてはいかがでしょうか?

Datastore/Go のデータ設計と struct の振る舞いについて

More Related Content

Similar to Datastore/Go のデータ設計と struct の振る舞いについて (19)

More from pospome (9)

Datastore/Go のデータ設計と struct の振る舞いについて