Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
値オブジェクトでアプリケーションコードを改変しよう
Search
tkitsunai
May 21, 2020
Technology
180
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
値オブジェクトでアプリケーションコードを改変しよう
車内のミートアップの発表資料
tkitsunai
May 21, 2020
More Decks by tkitsunai
See All by tkitsunai
TDD実践を経て変わったこと
tkitsunai
6
4.2k
Go活
tkitsunai
0
180
hbstudy#82 SRE大全 ソフトウェアエンジニアリングによるToil削減
tkitsunai
0
2.8k
Software Development in UZABASE SRE
tkitsunai
0
4k
Other Decks in Technology
See All in Technology
Kiro Crewで「みのるん式」仕事術やってみた
minorun365
PRO
4
1.1k
僕のハーネスを紹介します
watany
7
1.6k
[re:Invent2026事前勉強会(有志開催)]続きは、ラスベガスの廊下で / continue-in-the-vegas-hallway
sh_fk2
0
280
200人の配信コメント、 全部Jevが仕分けます 〜 マサカリガードを作ってみた 〜
katayamatg
1
200
2026-10-24 JAWS JAWS-UG 茨城 #18 IAM Policy Autopilotってなにさ。terraform planからIAM Policyつくれるの? / What's IAM Policy Autopilot
masasuzu
0
170
プロダクトが成長すると、 プロダクトマネージャーの仕事はどう変わるのか - 「まず作る」から「小さく学び、確かめながら進む」へ
sansantech
PRO
2
380
AI秘書と毎日働くのはもう当たり前。開発以外の業務に足りない機能をどう埋める?
minorun365
PRO
4
1.8k
freeeにおける AI を用いた ブラウザ動作確認の自動化の取り組み
freee
PRO
0
220
「作れる」と「リリースできる」の間にあったもの── PdMを外して見えた、PdMがやるべき仕事/Buildable ≠ Shippable: What Removing the PM Taught Me About the PM’s Job
yappli_developers
0
290
AI駆動開発における開発環境のセキュリティの考え方
yamahiro
2
620
FinOps Agentが生んだ技術負債:コスト自動調査の落とし穴と解消までの道のり
oasis1994liveforever
3
300
(swiftc) NonCopyableとライフタイム修飾子
teamhimeh
0
130
Featured
See All Featured
Groundhog Day: Seeking Process in Gaming for Health
codingconduct
0
440
Agile Leadership in an Agile Organization
kimpetersen
PRO
0
290
The Curse of the Amulet
leimatthew05
3
16k
[Rails World 2026] Durable orchestration on Rails: from continuation to workflow
palkan
1
940
It's Worth the Effort
3n
188
29k
The Invisible Side of Design
smashingmag
301
52k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
33
5.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
For a Future-Friendly Web
brad_frost
184
10k
HDC tutorial
michielstock
2
980
A designer walks into a library…
pauljervisheath
211
25k
Transcript
値オブジェクトで アプリケーションコードを改変しよう Takayuki Kitsunai
自己紹介 ・橘内 孝幸( Takayuki Kitsunai ) ・SaaS Product Division (
SPEEDAの色々を開発してます ) ・Gopher
発表の目的 ・なんとなく値オブジェクトを作っていないか、考えるきっかけを作りたい ・値オブジェクトになっていないコードを見たら、一緒にうずうずしたい
値オブジェクトについて ・Domain-Driven Designの構成要素の一つ 【特徴・特性】 ・一意性を持たない ・不変である ・計測/定量化/説明ができる
値オブジェクト、使ってますか?
値オブジェクト、「ちゃんと」使えてますか?
値オブジェクトたらしめる条件、その価値 1. 値が同じであれば同一であることを保証しているか(等価性) 2. 値の範囲を限定し、許容値をコントロールする 3. 不変化により、インスタンス化後のバグ混入を防ぐ(交換性) 4. それらを扱う名前が「計測/定量化/説明」をしているか これらの条件を満たすと、
表現力豊かに、コードがモノを矛盾なく説明できるようになる
値が同じであれば同一であることを保証する type PersonName struct { value string } func NewPersonName(value
string) PersonName { return PersonName{ value: value, } } name1 := NewPersonName("tkitsunai") name2 := NewPersonName("tkitsunai") if name1 == name2 { // true } ポイント:同一インスタンスかではなく値が同じであるか
値の範囲を限定し、許容値をコントロールする type SecurityCode struct { value int } func NewSecurityCode(value
int) (SecurityCode, error) { if value < 1300 || value > 9999 { return SecurityCode{}, errors.New("証券コードの値範囲外です ") } return SecurityCode{ value:value, }, nil } 例:東京証券取引所が扱う「証券コード」 ・1300番台〜9000番台から構成される
不変化により、インスタンス化後のバグ混入を防ぐ type SecurityCode struct { value int } func NewSecurityCode(value
int) (SecurityCode, error) { if value < 1300 || value > 9999 { return SecurityCode{}, errors.New("証券コードの値範囲外です ") } return SecurityCode{ value:value, }, nil } uzabase := NewSecurityCode("3396") // このようなことはできないようにする uzabase.value = 3397 ファクトリー関数やコンストラクタで不変化する
値オブジェクト警察をしてみよう type Company struct { name string address1 string address2
string listedFlag bool securityCode int phoneNumber string } こんなコードを見かけると、うずうずしてきませんか?
値オブジェクト警察への道 フェーズ1: プリミティブな値を探そう type Company struct { name string address1
string address2 string listedFlag bool securityCode int phoneNumber string } type Company struct { name Name address1 Address address2 Address listedFlag ListedStatus securityCode SecurityCode phoneNumber PhoneNumber }
値オブジェクト警察への道 フェーズ2: 名前が適切かを考えてみよう type Company struct { name Name address1
Address address2 Address listedFlag ListedStatus securityCode SecurityCode phoneNumber PhoneNumber } // 上場企業 type ListedCompany struct { } // 非上場企業 type UnlistedCompany struct { } // 企業の名前 type CompanyName struct { } // 人の名前 type PersonName struct { }
値オブジェクト警察への道 フェーズ3: それは値オブジェクトか?を考える 先の例では、「企業」を値オブジェクトとして作りました ・システムのコンテキスト範囲「企業」の扱い方によって、エンティティ (※1)になる ・値オブジェクトの特性から外れる場合に値オブジェクトのままで良いか? ※Eric Evans「ドメイン駆動設計」の「VALUE OBJECT」章のコラムをぜひご参照ください
まとめ ・値オブジェクトを知る - 「特徴・特性」を満たしてはじめて値オブジェクトと言える ・値オブジェクトが生み出す価値 - 表現力(説明力を含む)をあげる - 矛盾なきコードをつくる -
許容値のコントロールをする ・値オブジェクト警察 - プリミティブな値を使わない - 適切な名前か(値オブジェクトの条件「説明」ができるか) - これは値オブジェクトか否かを見極める
おわり