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
クリーンアーキテクチャを活かす考察
Search
kanayannet
November 14, 2021
Programming
1
290
クリーンアーキテクチャを活かす考察
kanayannet
November 14, 2021
Tweet
Share
More Decks by kanayannet
See All by kanayannet
無関心の谷
kanayannet
0
270
生成AIの使いどころ
kanayannet
0
160
github copilot と 心理的安全性
kanayannet
0
200
FW と ライブラリ の考え方
kanayannet
0
230
TDDと今まで
kanayannet
0
550
個人開発 稼げなくてもいいアプリ
kanayannet
0
520
システムの堅牢性
kanayannet
0
300
Agile的学習方法
kanayannet
0
280
GUIをエンジニアが考える
kanayannet
0
250
Other Decks in Programming
See All in Programming
AIに安心して任せるためにTypeScriptで一意な型を作ろう
arfes0e2b3c
0
270
Quality Gates in the Age of Agentic Coding
helmedeiros
PRO
1
110
Workers を定期実行する方法は一つじゃない
rokuosan
0
130
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
24
10k
What's new in Adaptive Android development
fornewid
0
120
TypeScriptでDXを上げろ! Hono編
yusukebe
3
880
テスターからテストエンジニアへ ~新米テストエンジニアが歩んだ9ヶ月振り返り~
non0113
2
240
Google I/O Extended Incheon 2025 ~ What's new in Android development tools
pluu
1
200
LLMは麻雀を知らなすぎるから俺が教育してやる
po3rin
2
1.3k
抽象化という思考のツール - 理解と活用 - / Abstraction-as-a-Tool-for-Thinking
shin1x1
1
860
slogパッケージの深掘り
integral0515
0
160
MCPで実現できる、Webサービス利用体験について
syumai
7
2.2k
Featured
See All Featured
Visualization
eitanlees
146
16k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Code Review Best Practice
trishagee
69
19k
The World Runs on Bad Software
bkeepers
PRO
70
11k
Why Our Code Smells
bkeepers
PRO
337
57k
Statistics for Hackers
jakevdp
799
220k
Thoughts on Productivity
jonyablonski
69
4.8k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
130
19k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Raft: Consensus for Rubyists
vanstee
140
7k
Transcript
Gunma.web #43 Gunma.web #43 クリーンアーキテクチャ を活かす考察 クリーンアーキテクチャ を活かす考察 @kanayannet
Agenda Agenda なぜ、やろうと思ったのか? 考察 活かし方 まとめ
なぜ、やろうと思ったのか? なぜ、やろうと思ったのか?
チームリーダとして作業の割り振りを考える
依存関係の切り方をしっかりやらないと.. 各担当者間でやり直しが多くなる 理由は... 後述で出します。
依存関係をしっかりと切れれば... 各担当者がハッピー deploy までスムーズ
そんな事を考えていると .. そんな事を考えていると .. クリーンアーキテクチャに遭遇 クリーンアーキテクチャに遭遇
この本ですね この本ですね
アーキテクチャのルールは アーキテクチャのルールは どれも同じである どれも同じである
アーキテクチャのルールは アーキテクチャのルールは どれも同じである どれも同じである 繰り返し 大事なのでリピート
何がどう同じなのか? 何がどう同じなのか? 話していきたいと思います。 話していきたいと思います。
考察 考察
この本実は ... この本実は ...
とにかく前振りが長い! とにかく前振りが長い!
どのくらい長いのかというと ... どのくらい長いのかというと ...
None
「 22 章」\ (^o^) / 「 22 章」\ (^o^) /
一体 21 章までは何を ... 一体 21 章までは何を ...
前振りが結構重要部分 前振りが結構重要部分
結論だけ聞いても「 ??? 」 結論だけ聞いても「 ??? 」
前振りの中で印象深いものを 前振りの中で印象深いものを いくつか話していきます。 いくつか話していきます。 すなわち、どのアーキテクチャにも共通する事
アーキテクチャの重要性 アーキテクチャの重要性 変更コストによって計測できる そもそも「変更のない開発」ってあるの? 初めに作ったものが「絶対」なんてのは... 少なくとも自分は経験ない by @kanayannet
設計とアーキテクチャに 設計とアーキテクチャに 何も違いはない 何も違いはない 概要だろうが詳細だろうが、設計でありアーキテクチャであ る よく分けて考える人がいるが... この本では「何も違いはない」と断言している
UI, ビジネスルール , DB アクセス UI, ビジネスルール , DB アクセス
ビジネスルールは独立させる事が可能 それだけでリリースも可能 DB やUI とは別のチームが開発可能
ソフトウェアの振るまい ソフトウェアの振るまい 簡単に振る舞いを変更できるため ソフト 振る舞いを変更できないもの ハード( ウェア) と呼んだ 既存の成果物を変更せず拡張できるようにすべき
SRP SRP 単一責任の原則 モジュールはたったひとつのアクターに対して責務を負うべ き 単一の修正が一つだけではなく複数の修正を誘発してしま うのは違反
OCP OCP オープンクローズドの原則 拡張に対しては開き、修正に対しては閉じてなくてはならな い 既存の成果物を変更せず拡張できるようにすべき
変化しやすい具象クラスを参照しない 変化しやすい具象クラスを参照しない 変化しやすいクラスを継承すると 変化のたびに変更が必要になる危険性があがる
循環依存は厄介 循環依存は厄介 あるコンポーネントの変更が 依存関係を循環し、自身にも悪 影響を与えてしまう
コンポーネント図 コンポーネント図 循環依存恐ければ図にしてみると良い
依存関係逆転 依存関係逆転 参照元と先を変更する事で循環依存を避けられる
.... もっと色々あるが ... .... もっと色々あるが ... そろそろ本題に入ります。 そろそろ本題に入ります。 詳しくはみなさんも是非読んでみて..
Clean Architecture Clean Architecture
エンティティ エンティティ ビジネスを表すものとして独立させる これがないとビジネスとして成立しない最低限の単位
ユースケース ユースケース 自動化されたシステムを使用する方法を記述したもの アプリケーション固有のビジネスルールを記述する 入力データを加工し適切なエンティティへの参照を実現する
この二つの依存関係 この二つの依存関係 エンティティは自身を制御するユースケースのことを知らな い。 エンティティもユースケースも通信手段やDB やフレームワー クの事は知らない そのくらい独立させておく( 汎用性を持たせる) DB,
http, その他外的要素がなくともテストできる
フレームワーク非依存 フレームワーク非依存 フレームワーク依存をなくす事でツールとして利用する
UI 非依存 UI 非依存 ビジネスルールの変更なしに変更できる http 経由 -> コンソールUI にするなど
外部エージェント依存 外部エージェント依存 ビジネルルールは外界のIF を知らない ブラウザ経由 -> アプリにする際に変更がない
活かし方 活かし方
頭の体操 頭の体操 DB, コード設計も含みます
どんな頭の使い方? どんな頭の使い方? 知らない = 無保証ではなく... 知らなくても動くようにする つまり依存をなくす方法を考える
一番大事なのは ... 一番大事なのは ... ビジネスを実現 ビジネスロジック や ビジネスルール と言われている箇所 これを
middleware で縛らない
コンポーネント図 コンポーネント図 絵にすると... 循環依存に気付きやすいよね?
これ RDB の外部キーでも これ RDB の外部キーでも 同じ事だよね? 同じ事だよね? 外部キーで循環依存は運用していくと厳しくなりそう。
難しいな ... 難しいな ... controller と web framework どう切り離せる?
とはいえ ... とはいえ ... ビジネスルールは切り離せそう ここ大事
まとめ まとめ
web framework controller 部分は結構結合している... 切り離し方知ってる人いる?
依存関係を整理していれば... ビジネスルールの分離はやれてる箇所はありそう とはいえ今後は意識したい
図や絵にする事大事 他の人と共有するときも -> 情報非対称性 対策 自分も気付きやすい
参考 参考 読んでいただければ、もっと色々と解ります。
ご清聴 ご清聴 ありがとう ありがとう ございました ございました