Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
DDD ユビキタス言語ってなあに?
Search
k.ishikawa
March 13, 2024
Programming
0
12
DDD ユビキタス言語ってなあに?
2023-03-13 社内勉強会で発表した資料です
k.ishikawa
March 13, 2024
Tweet
Share
More Decks by k.ishikawa
See All by k.ishikawa
DDD 値オブジェクトってなあに?
ishikawa096
0
25
正しいテスト駆動開発についてまとめてみた
ishikawa096
0
23
リソース効率とフロー効率についてざっくりまとめてみた
ishikawa096
0
12
ChatGPT×AWS LambdaのSlack Botを社内運用してみた
ishikawa096
1
48
Other Decks in Programming
See All in Programming
レガシーシステムにどう立ち向かうか 複雑さと理想と現実/vs-legacy
suzukihoge
14
2.2k
「今のプロジェクトいろいろ大変なんですよ、app/services とかもあって……」/After Kaigi on Rails 2024 LT Night
junk0612
5
2.2k
Hotwire or React? ~アフタートーク・本編に含めなかった話~ / Hotwire or React? after talk
harunatsujita
1
120
役立つログに取り組もう
irof
28
9.6k
GitHub Actionsのキャッシュと手を挙げることの大切さとそれに必要なこと
satoshi256kbyte
5
430
CSC509 Lecture 13
javiergs
PRO
0
110
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
260
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
100
ローコードSaaSのUXを向上させるためのTypeScript
taro28
1
630
受け取る人から提供する人になるということ
little_rubyist
0
250
as(型アサーション)を書く前にできること
marokanatani
10
2.7k
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
1
300
Featured
See All Featured
What's in a price? How to price your products and services
michaelherold
243
12k
A Modern Web Designer's Workflow
chriscoyier
693
190k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
The Invisible Side of Design
smashingmag
298
50k
Producing Creativity
orderedlist
PRO
341
39k
Unsuck your backbone
ammeep
668
57k
Speed Design
sergeychernyshev
25
620
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
What's new in Ruby 2.0
geeforr
343
31k
Bootstrapping a Software Product
garrettdimon
PRO
305
110k
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