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
kirimaru
July 18, 2023
Programming
0
220
DDD(ドメイン駆動設計)を知らない人に知ったつもりさせる/Introduce_DDD_to_unfamiliar_individuals
2022/07/14 19:00-21:00 テクシバNo.7
社内LT資料
kirimaru
July 18, 2023
Tweet
Share
More Decks by kirimaru
See All by kirimaru
例示! Spring Bootで作られた REST APIのテストコード/ Testing-Example-for-a-REST-API-created-with-Spring-Boot
hirotokirimaru
2
1.6k
一緒に使うことが多い値は別クラスにしよう(Data Clumps)/data_clumps_is_useful
hirotokirimaru
0
620
Backlogが好きな話。/i_like_backlog
hirotokirimaru
0
100
私が好きなポートアンドアダプターを紹介する/I-like-hexagonal-architecture.pdf
hirotokirimaru
1
750
名付けのためにクラス図を元に会話しよう/Let's-use-class-diagram-to-communicate-with-client
hirotokirimaru
0
570
Code Smellsの Primitive Obsession に気を付けて設計する/Designing-with-Code-Smells-Primitive-Obsession
hirotokirimaru
1
3.1k
FCCを推す/My favorite software architecture is FCC
hirotokirimaru
0
170
我々はなぜオブジェクト指向やDDD等のアーキテクチャを学ぶのか/Why_we_learn_ObjectOriented_and_DDD_Architecture
hirotokirimaru
1
1k
SLAPを覚えてリファクタリングに方針を/we learn slap for refactoring
hirotokirimaru
1
370
Other Decks in Programming
See All in Programming
リアーキテクチャxDDD 1年間の取り組みと進化
hsawaji
1
220
RubyLSPのマルチバイト文字対応
notfounds
0
120
ヤプリ新卒SREの オンボーディング
masaki12
0
130
受け取る人から提供する人になるということ
little_rubyist
0
250
Make Impossible States Impossibleを 意識してReactのPropsを設計しよう
ikumatadokoro
0
230
とにかくAWS GameDay!AWSは世界の共通言語! / Anyway, AWS GameDay! AWS is the world's lingua franca!
seike460
PRO
1
890
Jakarta EE meets AI
ivargrimstad
0
120
macOS でできる リアルタイム動画像処理
biacco42
9
2.4k
CSC509 Lecture 09
javiergs
PRO
0
140
Snowflake x dbtで作るセキュアでアジャイルなデータ基盤
tsoshiro
2
520
Quine, Polyglot, 良いコード
qnighy
4
650
Arm移行タイムアタック
qnighy
0
330
Featured
See All Featured
Happy Clients
brianwarren
98
6.7k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Java REST API Framework Comparison - PWX 2021
mraible
PRO
28
8.2k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
Mobile First: as difficult as doing things right
swwweet
222
8.9k
The Invisible Side of Design
smashingmag
298
50k
Into the Great Unknown - MozCon
thekraken
32
1.5k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
229
52k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5k
Ruby is Unlike a Banana
tanoku
97
11k
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/