Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Speaker Deck
PRO
Sign in
Sign up for free
クリーンアーキテクチャのすすめ
Taiga Sakaguchi
May 23, 2022
Programming
0
140
クリーンアーキテクチャのすすめ
Taiga Sakaguchi
May 23, 2022
Tweet
Share
More Decks by Taiga Sakaguchi
See All by Taiga Sakaguchi
トランクベース開発のすすめ
taigaskg
0
23
gRPC入門
taigaskg
0
64
Other Decks in Programming
See All in Programming
[2023년 1월 세미나] 데이터 분석가 되면 어떤 일을 하나요?
datarian
0
560
ペパカレで入社した私が感じた2つのギャップと向き合い方
kosuke_ito
0
160
AWSとCPUのムフフな関係
cmdemura
0
460
Functional Data Engineering - A Blueprint for adopting functional principles in data pipeline
vananth22
0
170
Findy - エンジニア向け会社紹介 / Findy Letter for Engineers
findyinc
2
42k
ちょうぜつ改め21世紀ふつうのソフトウェア設計
tanakahisateru
7
6.3k
Makuakeの認証基盤とRe-Architectureチーム
bmf_san
0
440
はてなリモートインターンシップ2022 インフラ 講義資料
hatena
4
2.1k
あなたと 「|」 したい・・・
track3jyo
PRO
2
1k
Showkase、Paparazziを用いたビジュアルリグレッションテストの導入にチャレンジした話 / MoT TechTalk #15
mot_techtalk
0
100
コンピュータビジョンセミナー2 / computer_vision_seminar_libSGM
fixstars
0
310
Listかもしれない
irof
1
200
Featured
See All Featured
Clear Off the Table
cherdarchuk
79
290k
How to train your dragon (web standard)
notwaldorf
66
4.2k
How STYLIGHT went responsive
nonsquared
89
4.2k
What’s in a name? Adding method to the madness
productmarketing
12
1.9k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
120
29k
The Cult of Friendly URLs
andyhume
68
5.1k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
270
12k
Designing for Performance
lara
600
65k
It's Worth the Effort
3n
177
26k
Streamline your AJAX requests with AmplifyJS and jQuery
dougneiner
128
8.8k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
152
13k
Practical Orchestrator
shlominoach
178
8.9k
Transcript
クリーンアーキテクチャ のすすめ 2022/05/22
坂口 大河 Sakaguchi Taiga 高校教員 → Web系エンジニア(3年目) バックエンドエンジニア 自己紹介 Go, Java, Vue.js, Nuxt.js,
GCP, AWS @taiga_skg taigaskg
クリーンアーキテクチャ
クリーンアーキテクチャ...? ヘキサゴナルアーキテクチャ オニオンアーキテクチャ レイヤードアーキテクチャ MVVM
最重要ルール レイヤーに分割し、関心事が分離されていること。 ソースコードの依存性は、内側だけに向かっていること。 (依存性のルール) 1 2
関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。
関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity(内部)間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller
関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。
関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity(内部)間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller
関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。
関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity(内部)間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller
関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。
関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity(内部)間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller
関心事の分離とは ビジネスロジック UI DB 外部API フレームワーク ユースケース etc... Entities ビジネスルールをカプセル化。メソッドやデータ構造をもつ。
関心事 レイヤー Usecases アプリケーション固有のビジネスルール。システムの全てのユースケ ースが実装されている。Entityの入出力を制御し、ユースケースの目 標を達成。 Interface Adapters 外部サービス・DB ↔︎ UsecaseやEntity(内部)間で便利な形式にデ ータ変換。 Frameworks & Drivers DBやWeb FWなどFWやツールで構成。コードはあまり書かない。書く としても、ひとつ内側のレイヤーとやり取りするための変換コード。 SQL Controller
依存性とは 依存しているとは、別のモジュールで定義された変数、関数、エンティティなどを使っていること Module A Module B Call
依存性のルール ソースコードの依存性は、内側だけに向かっていること。 内側の円は、外側の円について何も知ることはない。 外側から内側のものを呼び出す事は可能。 → 変数、関数、クラス、エンティティ、フォーマットなど 外側から内側に影響を与えるべきでない。 ※ 4つの円はあくまで概要。必ずしも4つの円である必要なない。
境界を越えるには? ユーザー登録のユースケースを考える。 Entities層(最内側)
Usecases層(内側) Interface Adapters層(外側)
依存性逆転の原則(DIP) 上位レベルの方針の実装コードは、下位レベルの詳細の実装コー ドに依存すべきでなく、逆に詳細が方針に依存すべきであるとい う原則
依存性逆転の原則(DIP) 上位レベルの方針の実装コードは、下位レベルの詳細の実装コー ドに依存すべきでなく、逆に詳細が方針に依存すべきであるとい う原則 ⇒ 具象ではなく、抽象に依存すべき
インターフェース とは
依存性逆転の原則(DIP) 具象ではなく、抽象に依存すべき ⇒ インターフェースに依存すべき。 Call Class A (Struct) Class B(Struct)
Interface Implement Call Boundary 内側
Entities層(最内側)
Usecases層(内側) Interface Adapters層(外側)
フレームワーク非依存 テスト可能 UI非依存 データベース非依存 外部エージェント非依存 何が嬉しいのか システムをFWの制約で縛る のではなく、ツールとして 利用できる。 UI、DB、Web
Server、 etc...がなくてもビジネスル ールのテストができる。 システムの他の部分を変更 することなくUIを変更でき る。 ビジネスルールはDBに束縛 されず、置き換え可能。 ビジネスルールは、外側の インターフェースについて 何も知らない。
ご清聴ありがとうございました!