Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DDD ユビキタス言語ってなあに?
Search
k.ishikawa
March 13, 2024
Programming
0
20
DDD ユビキタス言語ってなあに?
2023-03-13 社内勉強会で発表した資料です
k.ishikawa
March 13, 2024
Tweet
Share
More Decks by k.ishikawa
See All by k.ishikawa
DDD 値オブジェクトってなあに?
ishikawa096
0
110
正しいテスト駆動開発についてまとめてみた
ishikawa096
0
30
リソース効率とフロー効率についてざっくりまとめてみた
ishikawa096
0
18
ChatGPT×AWS LambdaのSlack Botを社内運用してみた
ishikawa096
1
63
Other Decks in Programming
See All in Programming
Spinner 軸ズレ現象を調べたらレンダリング深淵に飲まれた #レバテックMeetup
bengo4com
0
150
Implementation Patterns
denyspoltorak
0
110
TerraformとStrands AgentsでAmazon Bedrock AgentCoreのSSO認証付きエージェントを量産しよう!
neruneruo
4
1.6k
AIコーディングエージェント(skywork)
kondai24
0
200
Cell-Based Architecture
larchanjo
0
140
組み合わせ爆発にのまれない - 責務分割 x テスト
halhorn
1
160
Go コードベースの構成と AI コンテキスト定義
andpad
0
130
ELYZA_Findy AI Engineering Summit登壇資料_AIコーディング時代に「ちゃんと」やること_toB LLMプロダクト開発舞台裏_20251216
elyza
2
580
0→1 フロントエンド開発 Tips🚀 #レバテックMeetup
bengo4com
0
340
著者と進める!『AIと個人開発したくなったらまずCursorで要件定義だ!』
yasunacoffee
0
150
まだ間に合う!Claude Code元年をふりかえる
nogu66
5
890
生成AI時代を勝ち抜くエンジニア組織マネジメント
coconala_engineer
0
590
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
50
14k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
0
42
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Claude Code のすすめ
schroneko
65
200k
A better future with KSS
kneath
240
18k
We Have a Design System, Now What?
morganepeng
54
7.9k
[RailsConf 2023] Rails as a piece of cake
palkan
58
6.2k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
92
Designing Powerful Visuals for Engaging Learning
tmiket
0
180
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
34k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
What's in a price? How to price your products and services
michaelherold
246
13k
Transcript
DDD ユビキタス言語 コミュニケーションをスムーズにする命名
背景 ・昨年末〜のプロジェクトで、コード内の命名や 用語がバラバラになってしまった ・用語集などを作ればよかった ・言葉がバラバラだと知識の共有のためにオー バーヘッドが生じてよくない ↓ 新規プロジェクトで反省を生かすために、ユビ キタス言語について調べてみた
ユビキタス言語って何?
ユビキタス言語とは ・DDD(ドメイン駆動設計)で登場するコア概念の 1つ ・「いつでもどこでも使われる言葉」という意味
ユビキタス言語とは ・DDD(ドメイン駆動設計)で登場するコア概念の 1つ ・「いつでもどこでも使われる言葉」という意味 →超ざっくり言えば、 プロジェクトの関係者みんなの用語を統一しよう ということ
ユビキタス言語とは ・DDD(ドメイン駆動設計)で登場するコア概念の 1つ ・「いつでもどこでも使われる言葉」という意味 →超ざっくり言えば、 プロジェクトの関係者みんなの用語を統一しよう ということ 開発者はドメインエキスパート (ドメインの実践者・精通者。≠ステークホルダー)と同じ言葉を使おう
開発者 ドメインエキスパート 出典「ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本」
開発者 ドメインエキスパート 「ユーザを登録する 」 「ユーザを新規保存する 」 出典「ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本」
開発者 ドメインエキスパート 「ユーザを登録する 」 「ユーザを新規保存する 」 ユーザを登録するという 本質ではなく 「ユーザのデータをデータストアに新規保存する」 という具体的な処理に集中してしまう
出典「ドメイン駆動設計入門 ボトムアップでわかる! ドメイン駆動設計の基本」
開発者 ドメインエキスパート
開発者 ドメインエキスパート 薬A 薬B 薬C 薬を まとめて 渡すセット
開発者 ドメインエキスパート 薬A 薬B 薬C 薬を まとめて 渡すセット 薬A→一般薬 薬B
→ 医療薬 薬C → サプリ まとめたセット→パッケージ と呼びましょう
開発者 ドメインエキスパート 薬A 薬B 薬C 薬を まとめて 渡すセット 薬A→一般薬 薬B
→ 医療薬 薬C → サプリ まとめたセット→パッケージ と呼びましょう ドメインエキスパート側に ぴったりの用語が無かったり ふんわりしている場合、 命名を提案して 共通語になるようにする 提案 モデリング
そもそも開発者の間ですら 用語がバラバラ問題
用語がバラバラになっていく時 ・なんとなく表記揺れ 例) 正: 医療薬 → 医療用薬、医療薬品、医薬品 ・コード上で別の名前 例) Medicineクラスを作成
→ 「メディスンを登録」「メディスン周りの処理」といった発言
用語がバラバラになっていく時 ・なんとなく表記揺れ 例) 正: 医療薬 → 医療用薬、医療薬品、医薬品 ・コード上で別の名前 例) Medicineクラスを作成
→ 「メディスンを登録」「メディスン周りの処理」といった発言 ・行き当たりばったりの英訳 例) バックエンドではMedicineだがフロントエンドでは Drug
用語をバラバラにしないためには ・なんとなく表記揺れ ・コード上で別の名前
用語をバラバラにしないためには ・なんとなく表記揺れ → 正しい用語がどれなのかしっかり決めて用語集を書いておく。 意味が通じていても表記揺れしていたら 強い心で訂正する。 ・コード上で別の名前
用語をバラバラにしないためには ・なんとなく表記揺れ → 正しい用語がどれなのかしっかり決めて用語集を書いておく。 意味が通じていても表記揺れしていたら 強い心で訂正する。 ・コード上で別の名前 →英語/日本語の対応表を作る。 できるだけコード上でも同じ名前にする 。
用語をバラバラにしないためには ・なんとなく表記揺れ → 正しい用語がどれなのかしっかり決めて用語集を書いておく。 意味が通じていても表記揺れしていたら 強い心で訂正する。 ・コード上で別の名前 →英語/日本語の対応表を作る。 できるだけコード上でも同じ名前にする 。 ←できるのか?
コード上でも 同じ名前にできるのか
結論から言うと
結論から言うと できる
マルチバイト文字 (日本語など )が使えるプログラミング言語 ・ruby ※ただしClass名の1文字目は大文字である必要あり ・php ・JavaScript(ES2015以降) ・Java ・Swift ・Python3
・CSS ・mysql
日本語でプログラミングするとこんなメリットも ? ・コードを読む際に脳内翻訳しなくていい → 認知的負荷の大幅軽減 ※日本語というか日常的に使っている言語 「insurance card」…… えーと…… あっ「保険証」か これが認知的負荷
日本語でプログラミングするとこんなメリットも ? ・コードを読む際に脳内翻訳しなくていい → 認知的負荷の大幅軽減 ・命名のたびに英語を調べなくていい・綴りを確認しなくていい → 品質に無関係な余計な手間の消滅 ・綴り間違いや、使い慣れない英単語の取り違えによる バグ・事故がなくなる ※日本語というか日常的に使っている言語 「insurance
card」…… えーと…… あっ「保険証」か これが認知的負荷
日本語プログラミングのデメリットは? ・マルチバイト文字でバグが起きる可能性がある場合は使えない ・Postgresqlの一部機能?(未検証)など ・変換が必要なため、IDEで入力補完を効かせにくい ・「打ちやすさ」より「読みやすさ」が長期的に重要 と考えるか。 ・英単語の意味を調べる時間に比べれば、変換の時間の方が短い? ・チームが海外展開する予定・多言語環境の場合
新プロジェクトの DBを ローマ字表記で設計して感じたこと ・「〇〇って英語表記でどれ?」となることが無いので とてもわかりやすい ・複数形やBooleanのルールを先に決めた方が良さそう 例) ローマ字表記の場合もsをつけるか、日本語表記の場合「〇〇リスト」で統一するか ・どこまで日本語表記にするか の取り決めもあるといいかも
クラス名は日本語で統一、メソッド名 /関数名はできれば日本語、変数名は自由 など
参考記事 ・Webエンジニアはそろそろ日本語変数名の利用を検討してもいいのでは? https://zenn.dev/hedrall/articles/48dd7d8ae4fab7 ・変数名に日本語を使おう メリットとデメリット https://oopsoop.com/use-japanese-for-variable-names/ ・日本語プログラミングする時の名前の付け方を考える https://qiita.com/jpl_produire/items/7fe130f1fc7a41efd268