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
Flutterを言い訳にしない!アプリの使い心地改善テクニック5選🔥
kno3a87
1
170
PHP でアセンブリ言語のように書く技術
memory1994
PRO
1
170
cmp.Or に感動した
otakakot
2
150
ローコードSaaSのUXを向上させるためのTypeScript
taro28
1
610
Creating a Free Video Ad Network on the Edge
mizoguchicoji
0
120
Jakarta EE meets AI
ivargrimstad
0
540
よくできたテンプレート言語として TypeScript + JSX を利用する試み / Using TypeScript + JSX outside of Web Frontend #TSKaigiKansai
izumin5210
6
1.7k
Outline View in SwiftUI
1024jp
1
330
3 Effective Rules for Using Signals in Angular
manfredsteyer
PRO
0
100
Generative AI Use Cases JP (略称:GenU)奮闘記
hideg
1
290
Better Code Design in PHP
afilina
PRO
0
120
AWS Lambdaから始まった Serverlessの「熱」とキャリアパス / It started with AWS Lambda Serverless “fever” and career path
seike460
PRO
1
260
Featured
See All Featured
Building Applications with DynamoDB
mza
90
6.1k
Speed Design
sergeychernyshev
24
610
[RailsConf 2023] Rails as a piece of cake
palkan
52
4.9k
Optimizing for Happiness
mojombo
376
70k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
38
1.8k
It's Worth the Effort
3n
183
27k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
0
89
GraphQLの誤解/rethinking-graphql
sonatard
67
10k
Build The Right Thing And Hit Your Dates
maggiecrowley
33
2.4k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
44
2.2k
Making Projects Easy
brettharned
115
5.9k
10 Git Anti Patterns You Should be Aware of
lemiorhan
654
59k
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/