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(ドメイン駆動設計)を知らない人に知ったつもりさせる/Introduce_DDD_to_...
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
kirimaru
July 18, 2023
Programming
380
0
Share
DDD(ドメイン駆動設計)を知らない人に知ったつもりさせる/Introduce_DDD_to_unfamiliar_individuals
2022/07/14 19:00-21:00 テクシバNo.7
社内LT資料
kirimaru
July 18, 2023
More Decks by kirimaru
See All by kirimaru
早くAPI作るならFastAPI がオススメ
hirotokirimaru
1
120
例示! Spring Bootで作られた REST APIのテストコード/ Testing-Example-for-a-REST-API-created-with-Spring-Boot
hirotokirimaru
2
2.2k
一緒に使うことが多い値は別クラスにしよう(Data Clumps)/data_clumps_is_useful
hirotokirimaru
0
800
Backlogが好きな話。/i_like_backlog
hirotokirimaru
0
180
私が好きなポートアンドアダプターを紹介する/I-like-hexagonal-architecture.pdf
hirotokirimaru
1
1.4k
名付けのためにクラス図を元に会話しよう/Let's-use-class-diagram-to-communicate-with-client
hirotokirimaru
0
680
Code Smellsの Primitive Obsession に気を付けて設計する/Designing-with-Code-Smells-Primitive-Obsession
hirotokirimaru
1
3.8k
FCCを推す/My favorite software architecture is FCC
hirotokirimaru
0
280
我々はなぜオブジェクト指向やDDD等のアーキテクチャを学ぶのか/Why_we_learn_ObjectOriented_and_DDD_Architecture
hirotokirimaru
1
1.1k
Other Decks in Programming
See All in Programming
「エンジニアインターン、どうやって取った?」準備のリアルを語るLT会 Progate BAR
akiomatic
0
100
Signal Forms: Beyond the Basics @ngBaguette 2026 in Paris
manfredsteyer
PRO
0
180
OCRを使ってゲームのアイテムをデータ化する
kishikawakatsumi
0
120
作って学ぶ、 JSX (TSX) ランタイムの基本
syumai
7
1k
Hive Metastoreを通して学ぶIceberg REST Catalog ― 仕様から実装まで
okumin
0
310
密結合なバックエンドから TypeScript のコードを生成する
kemuridama
1
390
Make SRE Operations Easier with Azure SRE Agent
kkamegawa
0
2.2k
Oxcを導入して開発体験が向上した話
yug1224
4
260
AIチームを指揮するOSS「TAKT」活用術 / How to Use “TAKT,” an OSS Tool for Orchestrating AI Teams
nrslib
6
760
技術記事、AIに書かせるか、自分で書くか? 〜それでも私が自分の手で書く理由〜 / #QiitaConference
jnchito
2
1.2k
SPMマルチモジュールで テストカバレッジを取得する技法
yosshi4486
0
130
柔軟なPDFレイアウトエディタを支える型システム設計 — Discriminated UnionとConditional Typeの実践
minako__ph
4
1.2k
Featured
See All Featured
Embracing the Ebb and Flow
colly
88
5.1k
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
520
A better future with KSS
kneath
240
18k
Balancing Empowerment & Direction
lara
6
1.1k
The Straight Up "How To Draw Better" Workshop
denniskardys
239
140k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.5k
Stop Working from a Prison Cell
hatefulcrawdad
274
21k
How to Think Like a Performance Engineer
csswizardry
28
2.6k
Building Flexible Design Systems
yeseniaperezcruz
330
40k
Why Our Code Smells
bkeepers
PRO
340
58k
Navigating Team Friction
lara
192
16k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
210
Transcript
DDD(ドメイン駆動設計)を 知らない人に 知ったつもりさせる 2023/07/14 19:00-21:00 テクシバVol.7 ソフトバンク IT統括 ビジネスシステム開発本部 法人システム統括部
データシステム部 法人Webシステム課 水上 皓登(きり丸)@nainaistar
名前:水上 皓登(きり丸) twitter1 :nainaistar twitter2 :mizuHiroto GitHub :hirotoKirimaru ブログ :きり丸の技術日記
https://nainaistar.hatenablog.com/ 2 ひとこと: DDD警察怖い 2014-2019 :中小SIer 2019- :ソフトバンク
DDDとは
DDDとは Domain-Driven Design(ドメイン駆動設計)のこと。 エリック・エヴァンスが提唱した 問題解決にフォーカスした設計パターン。 内容自体は良書だが、 表現が非常に回りくどいので 読むのが大変。 通称:エヴァンス本
DDDで大事なこと
DDDで大事なこと 全員で同じ意味を持った単語でコミュニケーションを取ること。 SB固有の共通のシステム名や単語もたくさん 上の概念が理解出来たら、DDDは80%理解できています
何が難しいのか
何が難しいのか 実装都合で誰も使っていない概念を使用してしまう。 現実の概念だとN:Nの関係性を持つことが多いが、 それだとシステムが作れないので、中間テーブル等々で 1:Nの関係性にする必要がある その結果、会話をしていく中で齟齬が出てきてしまう
何が難しいのか また、単数と複数で表現が異なったり、状態によって表現が異なることもある。 概念自体があいまいかもしれない。 プログラム上で表現するのは難しい。 保護者、支払者、利用者、全部がUserクラス。
何が難しいのか プログラム化するときに、和製英語など英語と日本語の持つ意味が違う receipt ←レシート? 領収書? invoice ←請求書? インボイス対応のための書類…? 情報が欠落しがち。 日本語で表現していることは、素直に日本語で表現した方が
コードは読みやすい
何が難しいのか この概念をコードに落とし込む難しい作業を どうやって解決したらよいか、 という点がDDDの残り20% とはいえ、 エヴァンスさんが当時考えたテクニック集でしかないので、 本の通りに実装することがDDDではない
同じ単語で会話
同じ単語で会話 コード上では、システムは共通で認識している単語として扱う 機能ベースの命名にせず、システム名も併用した方がプロジェクト参加者には 伝わる 特に社内システムの場合、システム名を使った方が保守性は上がる。 ただし、転職直後・開発だけ参加するメンバーが多い場合は、社内システムを 理解する時間が多くなり、コストが見合わない可能性はある。
特化する
特化する ユーザーといった表現ではなく、可能な限り特化することが必要 特化すると、持つべき属性が見えてくる 例:保護者 = 18才以上(成人) 支払者 = 口座情報等の支払手段がある 利用者
= 条件なし どういうロールで扱っているかを把握するとわかりやすくなる
大事な概念
大事な概念 一番大事な概念が何かを掴む 例:水上がソフトバンクで通話できる携帯を契約した • 契約者(水上)が一番大事? • 携帯が一番大事? • 携帯の電話番号が一番大事? •
通話できるサービスが一番大事?
大事な概念 あくまで、システムの状況による前提で。 • 契約者(水上)が一番大事? • 携帯が一番大事? • 携帯の電話番号が一番大事? • 通話できるサービスが一番大事?
=> SMS認証できるし、電話番号が一番安定した概念
大事な概念 電話番号が一番大事な概念である前提で、色んな機能が増えていく • 携帯を複数台持つ場合 • 一括支払をする場合 ◦ 本人だけでなく、家族も含めた支払 ▪ 電話番号がベースだと人の関係性が簡単に取得できない
慣れないと利便性が悪いシステムだと思ってしまうが、 重要な概念を理解できると芋づる式に理解できる
脱線して 素うどん理論
素うどん理論 (リクルート ホールディングスCEO出木場 久征) 引用: 僕は一緒に働くチームのみんなに対して「まずは美味しい“素うどん”を作ろう」 と話しています。もしうどん店を経営しているとして、売上や利益を上げるのは どうしたらいいかと考える時、商圏や客層に合わせて単価をいくらに設定しよう とか、天ぷらを載せてみたらどうか、お得感のある定食メニューを作ってみては どうかとテクニックに走ってしまいがちです。でも本当に大事なことは、やっぱり
出汁が効いていて麺がめちゃくちゃ美味しい最高の素うどんを作れるかどうか だと思うんです。
素うどん理論 次の二つを解決するための手段がDDD • 大事な概念の価値の最大化 • 大事な概念の開発生産性を高める 保守性、開発容易性にリーチした手法がDDD 大事なのは、「おいしい素うどん」という概念を磨くこと
まとめ
1. 同じ意味の単語で会話する 2. 会話で重要な概念に気づく 3. 気づいた重要な概念を磨く 4. 磨くうちに、違う捉え方ができるかも
Appendix
引用元 素うどん理論 https://recruit-holdings.com/ja/blog/post_20221108_0001/