Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
GoとMicroserviceでDDDやってみました
Search
hitsuji-haneta
April 20, 2020
Programming
420
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
GoとMicroserviceでDDDやってみました
hitsuji-haneta
April 20, 2020
More Decks by hitsuji-haneta
See All by hitsuji-haneta
SSIで覗き見るPWAの世界 / SSI on PWA
hitsuji_haneta
2
1.2k
やってみたよVueNative
hitsuji_haneta
2
510
これもフロントエンド!画面つきスピーカーで遊んでみた
hitsuji_haneta
0
120
VueではじめるWeb Components
hitsuji_haneta
1
590
webエンジニア向けブロックチェーンの技術的「へぇ」 / Blockchain tech tips for web developers
hitsuji_haneta
0
170
Other Decks in Programming
See All in Programming
半永久的に提供し続けられるプライベートクラウドを目指して ― 利用者の認知負荷を抑えるAPI抽象化とハードウェア世代交代の基盤設計
tomokon
0
520
Vue Fes Japan の “作る側”に関わってみて
naokihaba
1
180
Web Framework Benchmark Battle 2026, Any%
a_matsuda
2
2.7k
Simple Storage Service(S3) is not simple
iwatsukayura
0
310
AI時代のTerminal環境を UNIX哲学で設計・運用する
yasunori0418
1
200
AIに “答え“を書かせるのを やめてみた
___akari11
0
130
月間100万人のサービス刷新で、 技術選定をHonoに振り切った話
yutobara
8
6.8k
JIS keyboard support in Omarchy
lef237
0
150
なぜCTOを降りてFDEを選んだのか?〜なぜプロダクト企業がFDEで顧客の現場に踏み込むのか〜
gonta
1
230
Unity6 URPによる海底をテーマにしたVJシステムの解説 | Unity Shader 完全に理解した 勉強会
gam0022
0
370
IBM Bob でAI駆動開発『QC-Playbook』
ichirokano2
0
120
コードで差別化できない時代の ソフトウェアエンジニアリング / Software Engineering in an Era Where Code Doesn’t Differentiate
kishida
2
190
Featured
See All Featured
SEO for Brand Visibility & Recognition
aleyda
0
4.8k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
12k
So, you think you're a good person
axbom
PRO
2
2.2k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
860
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.9k
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
590
The Mindset for Success: Future Career Progression
greggifford
PRO
0
540
Ten Tips & Tricks for a 🌱 transition
stuffmc
1
270
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
320
Typedesign – Prime Four
hannesfritz
42
3.2k
The innovator’s Mindset - Leading Through an Era of Exponential Change - McGill University 2025
jdejongh
PRO
1
380
エンジニアに許された特別な時間の終わり
watany
109
250k
Transcript
やってみました Go MicroService DDD で と 2020/04/20 DDD Talk Meetup
Online
高橋翔太 hitsuji-haneta LasTrust株式会社 h1tsuj1_haneta https://lastrust.io ・ブロックチェーン証明書の発行 ・証明書の管理アプリの開発 (ヒツジハネタ) ࣗݾհ
教育機関・金融機関・自治体など ࣗݾհ 個人の見えざる価値を可視化する
Go Sendai 2020/7/4 Conference
Go言語+MicroServicesで構築していた 弊社サービスにDDDを導入してみました ・DDDを導入しようとしたきっかけ ・マイクロサービスから見たDDD ・Go言語から見たDDD(アーキテクチャ) ・所感
DDDは初心者です よくない設計もあるかも知れないので お気づきの方は懇親会で教えて下さい
Service A Service C Service B %%%ಋೖͷ͖͔͚ͬɹ サービスの数が増えてきた ◦◦を元にした設計 ✕✕な感じの設計
Service D Service E △△風な設計 つらい…
%%%ಋೖͷ͖͔͚ͬɹ → ちゃんとドキュメントを残せばいい? → 最小限にしたい → チームとして共通の設計認識を持って それを規律としていきたい 個々のサービスの設計思想がバラバラ&追えない
DDDはどうだろう??
Go言語 マイクロサービス
Go言語 マイクロサービス
ϚΠΫϩαʔϏε͔Βݟͨ%%%ɹ Service A Service C Service B DDDを元にした設計 DDDを元にした設計 Service
D Service E DDDを元にした設計 見やすい! レビューしやすい!
ϚΠΫϩαʔϏε͔Βݟͨ%%%ɹ Service A Service C Service B Service D Service
E 予期していなかった効果 → 境界づけられたコンテキスト 実はマージした方が いいのでは?
ϚΠΫϩαʔϏε͔Βݟͨ%%%ɹ それまで 「責務の分離」に応じてサービスを区切っていた DDD導入後 BUT 意外にそこの解釈は人による… 基準ができた!
Go言語 マイクロサービス
(Pݴޠ͔Βݟͨ%%%ɹ Go言語の特徴 ・実行速度が速い ・並列処理が簡単 ・シンプルな言語構造 Class構文がない Interfaceはある でも継承はない
(Pݴޠ͔Βݟͨ%%%ɹ どういうこと? type dog struct { id uint name string
} func(d *dog) Cry() string { return “Bow!" } type Animal interface { Cry() string } func test(a Animal) { fmt.Printf(a.Cry()) } メソッドは構造体(struct)に紐付ける Interfaceに定義されたメソッドと 同じものが定義された構造体はそ のInterfaceとして使用できる
(Pݴޠ͔Βݟͨ%%%ɹ Goで有名な考え方 accept interfaces, return structs. 関数はインターフェースを受け入れて 構造体を返すように作りましょう
type someStc struct { id uint name string } type
SomeIf interface { CreateStc() someStc } func Test(i SomeIf) *someStc { return i.CreateStc } (Pݴޠ͔Βݟͨ%%%ɹ Func Interface ダックタイピングに近い Interfaceは使う人が定義する (同じpackage内とか) Struct
(Pݴޠ͔Βݟͨ%%%ɹ IssueCertificate() Issuerドメイン 証明書を発行して ストレージに格納 S3 GCS ファイル システム Storage
Adapter S3 Adapter 外から渡す インターフェースは どこで定義する?
(Pݴޠ͔Βݟͨ%%%ɹ Issuerドメイン IssueCertificate() Storage Adapter S3 Adapter Interfaceは使う人が定義 シンプルになった!
まとめ ・マイクロサービスの設計に明確な基準ができた ・「accept interfaces, return structs.」の 考え方を使えば置き場所の悩みがスッキリする 懸念 ・Interfaceの置き方がコレでいのかという
不安はある。詳しい方の見解聞きたい!
ありがとうございました!