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
230
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.7k
一緒に使うことが多い値は別クラスにしよう(Data Clumps)/data_clumps_is_useful
hirotokirimaru
0
630
Backlogが好きな話。/i_like_backlog
hirotokirimaru
0
110
私が好きなポートアンドアダプターを紹介する/I-like-hexagonal-architecture.pdf
hirotokirimaru
1
790
名付けのためにクラス図を元に会話しよう/Let's-use-class-diagram-to-communicate-with-client
hirotokirimaru
0
580
Code Smellsの Primitive Obsession に気を付けて設計する/Designing-with-Code-Smells-Primitive-Obsession
hirotokirimaru
1
3.2k
FCCを推す/My favorite software architecture is FCC
hirotokirimaru
0
180
我々はなぜオブジェクト指向やDDD等のアーキテクチャを学ぶのか/Why_we_learn_ObjectOriented_and_DDD_Architecture
hirotokirimaru
1
1k
SLAPを覚えてリファクタリングに方針を/we learn slap for refactoring
hirotokirimaru
1
380
Other Decks in Programming
See All in Programming
複雑な仕様に立ち向かうアーキテクチャ
myohei
0
170
DevFest Tokyo 2025 - Flutter のアプリアーキテクチャ現在地点
wasabeef
5
900
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
930
競技プログラミングへのお誘い@阪大BOOSTセミナー
kotamanegi
0
360
ドメインイベント増えすぎ問題
h0r15h0
1
230
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
240
創造的活動から切り拓く新たなキャリア 好きから始めてみる夜勤オペレーターからSREへの転身
yjszk
1
130
StarlingMonkeyを触ってみた話 - 2024冬
syumai
3
270
PHPで作るWebSocketサーバー ~リアクティブなアプリケーションを知るために~ / WebSocket Server in PHP - To know reactive applications
seike460
PRO
2
110
これが俺の”自分戦略” プロセスを楽しんでいこう! - Developers CAREER Boost 2024
niftycorp
PRO
0
190
42 best practices for Symfony, a decade later
tucksaun
1
180
短期間での新規プロダクト開発における「コスパの良い」Goのテスト戦略」 / kamakura.go
n3xem
2
170
Featured
See All Featured
The Cult of Friendly URLs
andyhume
78
6.1k
Optimising Largest Contentful Paint
csswizardry
33
3k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
28
4.4k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
2
170
Typedesign – Prime Four
hannesfritz
40
2.4k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
0
97
We Have a Design System, Now What?
morganepeng
51
7.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Making the Leap to Tech Lead
cromwellryan
133
9k
Keith and Marios Guide to Fast Websites
keithpitt
410
22k
Gamification - CAS2011
davidbonilla
80
5.1k
Statistics for Hackers
jakevdp
796
220k
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/