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
how to determine architecture
Search
hiroaki
October 08, 2022
Technology
310
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
how to determine architecture
hiroaki
October 08, 2022
More Decks by hiroaki
See All by hiroaki
leadership-that-endures-book-lt
hiroaki_u
0
55
プロダクト負債に立ち向かう
hiroaki_u
2
2.2k
pdm_vibe_coding_fail.pdf
hiroaki_u
0
240
Communication with Ubiquitous Language
hiroaki_u
0
120
the-concept-of-product-creation-learned-in-startup-science
hiroaki_u
0
190
what-is-container
hiroaki_u
1
130
difference-between-nginx-and-apache
hiroaki_u
0
100
CI_CD_by_Code_Brothers_by_AWS
hiroaki_u
0
65
think of study
hiroaki_u
1
140
Other Decks in Technology
See All in Technology
小規模OSSモデルは サイバーセキュリティ業務に どこまで使えるか
bbrbbq
0
300
FinOps Agentが生んだ技術負債:コスト自動調査の落とし穴と解消までの道のり
oasis1994liveforever
3
300
プロダクトが成長すると、 プロダクトマネージャーの仕事はどう変わるのか - 「まず作る」から「小さく学び、確かめながら進む」へ
sansantech
PRO
1
370
Teaching Python with three kinds of AI
reuven
0
120
日本AIベンチャーレポート2026
kentarofujii
0
240
構造で守らせる データ・法務・セキュリティ・開発チームとつくる AI時代のデータガバナンスとデータ基盤のリアル
legalontechnologies
PRO
1
520
これだけは抑えておきたい!後悔しない re:Invent の過ごし方 / AWS re:Invent 2026 prestudy
kinunori
2
380
局所最適は悪ではない。壊れているのは指標です。量と質を同時に見る先行指標の設計
recruitengineers
PRO
2
1.2k
What Is JetBrains Air
x5gtrn
PRO
0
170
「私が一番顧客に詳しい」を捨てる~ 全員が一次情報に精通する開発チームをつくり、PMが次のボトルネックへ染み出すまで
kaminashi
4
2.4k
"計画的無茶振り"を通してAIネイティブ世代の新人を育てる
subroh0508
1
110
CTO Night|NotionのAIエージェントとFDE
kzkhykw1991
0
320
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
96
14k
The Illustrated Children's Guide to Kubernetes
chrisshort
51
53k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
490
Gemini Prompt Engineering: Practical Techniques for Tangible AI Outcomes
mfonobong
2
600
Making Projects Easy
brettharned
120
6.8k
Scaling GitHub
holman
464
140k
Ruling the World: When Life Gets Gamed
codingconduct
0
420
Building an army of robots
kneath
307
47k
RailsConf 2023
tenderlove
30
1.6k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.2k
Technical Leadership for Architectural Decision Making
baasie
3
610
Mobile First: as difficult as doing things right
swwweet
225
10k
Transcript
アーキテクチャって どうやって決めれば良いの?? hiroaki
Who am I ? 上田 裕耀(28) Backend, Infra, DevOps 2018/04〜
食品メーカーの研究所 2021/03〜 Webエンジニア 経歴 神奈川→埼玉→群馬→神奈川 趣味 サウナ & 筋トレ
そもそもアーキテクチャとは??
(と思っています) アプリケーションの課題を 解決するための構造
アプリケーションの課題は色々ある コスト スケーラビリティ 保守改修性 パフォーマンス セキュリティ 可用性
何かを優先すると他のレベルが下がってしまう。 トレードオフの構造
アプリケーションの構造も色々 モノリス 分散システム 同期 非同期 内部のレイヤー構造 or or
結局、アーキテクチャって どうやって決めれば良いの??
ビジネスの要求に柔軟に対応できるような アーキテクチャを目指す 使う技術に依存しない構造 仕様の変更しやすい構造 アプリケーション課題に合わせた構造
引用:『ソフトウェアアーキテクチャの基礎』P.250 図17-1』 アプリケーション課題に合わせた構造 例:マイクロサービス
引用:『ソフトウェアアーキテクチャの基礎』P.263 図17-9』 ⭕ 拡張性、保守改修性 etc. ❌ DBの一貫性、コスト etc. アプリケーション課題に合わせた構造
使う技術に依存しない構造 アプリケーション
使う技術に依存しない構造 例:オニオンアーキテクチャ
SOLID原則やデザインパターンあたりが効果的 仕様の変更しやすい構造 S O L I D 単一責任の原則 オープン・クローズドの原則 リスコフの置換原則
インターフェース分離の原則 依存性逆転の原則
常にアプリケーションの課題を考え続けて、 betterな選択をしていく。 各サービス内では、独立性を高めた 保守改修性の高い設計を目指す。
Reference
ご清聴ありがとうございました!