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
how to determine architecture
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
hiroaki
October 08, 2022
Technology
260
1
Share
how to determine architecture
hiroaki
October 08, 2022
More Decks by hiroaki
See All by hiroaki
leadership-that-endures-book-lt
hiroaki_u
0
18
プロダクト負債に立ち向かう
hiroaki_u
2
1.8k
pdm_vibe_coding_fail.pdf
hiroaki_u
0
190
Communication with Ubiquitous Language
hiroaki_u
0
100
the-concept-of-product-creation-learned-in-startup-science
hiroaki_u
0
180
what-is-container
hiroaki_u
1
100
difference-between-nginx-and-apache
hiroaki_u
0
82
CI_CD_by_Code_Brothers_by_AWS
hiroaki_u
0
54
think of study
hiroaki_u
1
110
Other Decks in Technology
See All in Technology
『生成AI時代のクレデンシャルとパーミッション設計 — Claude Code を起点に』の執筆企画
takuros
3
2.3k
大学職員のための生成AI最前線 :最前線を、AIガバナンスとして読み直すためのTips
gmoriki
2
4k
AI駆動開発で生産性を追いかけたら、行き着いたのは品質とシフトレフトだった
littlehands
0
490
「強制アップデート」か「チームの自律」か?エンタープライズが辿り着いたプラットフォームのハイブリッド運用/cloudnative-kaigi-hybrid-platform-operations
mhrtech
0
180
なぜ、私がCommunity Builderに?〜活動期間1か月半でも選出されたワケ〜
yama3133
0
120
ボトムアップ限界を越える - 20チームを束る "Drive Map" / Beyond Bottom-Up: A 'Drive Map' for 20 Teams
kaonavi
0
190
クラウドネイティブ DB はいかにして制約を 克服したか? 〜進化歴史から紐解く、スケーラブルアーキテクチャ設計指針〜
hacomono
PRO
6
920
「QA=テスト」「シフトレフト=スクラムイベントの参加者の一員」の呪縛を解く。アジャイルな開発を止めないために、10Xで挑んだ「右側のしわ寄せ」解消記 #scrumniigata
nihonbuson
PRO
5
1.2k
拝啓、あの夏の僕へ〜あなたも知っているApp Runnerの世界〜
news_it_enj
0
240
Oracle AI Database@AWS:サービス概要のご紹介
oracle4engineer
PRO
4
2.5k
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
100k
全社統制を維持しながら現場負担をどう減らすか〜プラットフォームチームとセキュリティチームで進めたSecurity Hub活用によるAWS統制の見直し〜/secjaws-security-hub-custom-insights
mhrtech
1
410
Featured
See All Featured
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
280
Designing Experiences People Love
moore
143
24k
How People are Using Generative and Agentic AI to Supercharge Their Products, Projects, Services and Value Streams Today
helenjbeal
1
180
Tips & Tricks on How to Get Your First Job In Tech
honzajavorek
1
500
My Coaching Mixtape
mlcsv
0
120
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
PRO
1
1.2k
Bash Introduction
62gerente
615
210k
Everyday Curiosity
cassininazir
0
200
Paper Plane (Part 1)
katiecoart
PRO
0
7.3k
Leo the Paperboy
mayatellez
7
1.8k
Testing 201, or: Great Expectations
jmmastey
46
8.1k
[SF Ruby Conf 2025] Rails X
palkan
2
1k
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
ご清聴ありがとうございました!