Gunma.web #43Gunma.web #43クリーンアーキテクチャ を活かす考察クリーンアーキテクチャ を活かす考察@kanayannet
View Slide
AgendaAgendaなぜ、やろうと思ったのか？考察活かし方まとめ
なぜ、やろうと思ったのか？なぜ、やろうと思ったのか？
チームリーダとして作業の割り振りを考える
依存関係の切り方をしっかりやらないと..各担当者間でやり直しが多くなる理由は...後述で出します。
依存関係をしっかりと切れれば...各担当者がハッピーdeployまでスムーズ
そんな事を考えていると..そんな事を考えていると..クリーンアーキテクチャに遭遇クリーンアーキテクチャに遭遇
この本ですねこの本ですね
アーキテクチャのルールはアーキテクチャのルールはどれも同じであるどれも同じである
アーキテクチャのルールはアーキテクチャのルールはどれも同じであるどれも同じである繰り返し大事なのでリピート
何がどう同じなのか？何がどう同じなのか？話していきたいと思います。話していきたいと思います。
考察考察
この本実は...この本実は...
とにかく前振りが長い！とにかく前振りが長い！
どのくらい長いのかというと...どのくらい長いのかというと...
「22章」＼(^o^)／「22章」＼(^o^)／一体21章までは何を...一体21章までは何を...
前振りが結構重要部分前振りが結構重要部分
結論だけ聞いても「???」結論だけ聞いても「???」
前振りの中で印象深いものを前振りの中で印象深いものをいくつか話していきます。いくつか話していきます。すなわち、どのアーキテクチャにも共通する事
アーキテクチャの重要性アーキテクチャの重要性変更コストによって計測できるそもそも「変更のない開発」ってあるの？初めに作ったものが「絶対」なんてのは...少なくとも自分は経験ない by @kanayannet
設計とアーキテクチャに設計とアーキテクチャに何も違いはない何も違いはない概要だろうが詳細だろうが、設計でありアーキテクチャであるよく分けて考える人がいるが...この本では「何も違いはない」と断言している
UI,ビジネスルール, DBアクセスUI,ビジネスルール, DBアクセスビジネスルールは独立させる事が可能それだけでリリースも可能DBやUIとは別のチームが開発可能
ソフトウェアの振るまいソフトウェアの振るまい簡単に振る舞いを変更できるためソフト振る舞いを変更できないものハード(ウェア)と呼んだ既存の成果物を変更せず拡張できるようにすべき
SRPSRP単一責任の原則モジュールはたったひとつのアクターに対して責務を負うべき単一の修正が一つだけではなく複数の修正を誘発してしまうのは違反
OCPOCPオープンクローズドの原則拡張に対しては開き、修正に対しては閉じてなくてはならない既存の成果物を変更せず拡張できるようにすべき
変化しやすい具象クラスを参照しない変化しやすい具象クラスを参照しない変化しやすいクラスを継承すると変化のたびに変更が必要になる危険性があがる
循環依存は厄介循環依存は厄介あるコンポーネントの変更が 依存関係を循環し、自身にも悪影響を与えてしまう
コンポーネント図コンポーネント図循環依存恐ければ図にしてみると良い
依存関係逆転依存関係逆転参照元と先を変更する事で循環依存を避けられる
....もっと色々あるが.......もっと色々あるが...そろそろ本題に入ります。そろそろ本題に入ります。詳しくはみなさんも是非読んでみて..
Clean ArchitectureClean Architecture
エンティティエンティティビジネスを表すものとして独立させるこれがないとビジネスとして成立しない最低限の単位
ユースケースユースケース自動化されたシステムを使用する方法を記述したものアプリケーション固有のビジネスルールを記述する入力データを加工し適切なエンティティへの参照を実現する
この二つの依存関係この二つの依存関係エンティティは自身を制御するユースケースのことを知らない。エンティティもユースケースも通信手段やDBやフレームワークの事は知らないそのくらい独立させておく(汎用性を持たせる)DB, http,その他外的要素がなくともテストできる
フレームワーク非依存フレームワーク非依存フレームワーク依存をなくす事でツールとして利用する
UI非依存UI非依存ビジネスルールの変更なしに変更できるhttp経由 ->コンソールUIにするなど
外部エージェント依存外部エージェント依存ビジネルルールは外界のIFを知らないブラウザ経由 ->アプリにする際に変更がない
活かし方活かし方
頭の体操頭の体操DB,コード設計も含みます
どんな頭の使い方？どんな頭の使い方？知らない =無保証ではなく...知らなくても動くようにするつまり依存をなくす方法を考える
一番大事なのは...一番大事なのは...ビジネスを実現ビジネスロジック や ビジネスルール と言われている箇所これを middlewareで縛らない
コンポーネント図コンポーネント図絵にすると...循環依存に気付きやすいよね？
これRDBの外部キーでもこれRDBの外部キーでも同じ事だよね？同じ事だよね？外部キーで循環依存は運用していくと厳しくなりそう。
難しいな...難しいな...controllerと web frameworkどう切り離せる?
とはいえ...とはいえ...ビジネスルールは切り離せそうここ大事
まとめまとめ
web frameworkcontroller部分は結構結合している...切り離し方知ってる人いる?
依存関係を整理していれば...ビジネスルールの分離はやれてる箇所はありそうとはいえ今後は意識したい
図や絵にする事大事他の人と共有するときも ->情報非対称性 対策自分も気付きやすい
参考参考読んでいただければ、もっと色々と解ります。
ご清聴ご清聴ありがとうありがとうございましたございました
kanayannet
zakky21
bells17
miciek
mugi_uno
os1ma
morikann
ykws
rakus_dev
ivargrimstad
tomokusaba
toricky6
sanfrecce_osaka
palkan
sachag
skipperchong
bermonpainter
edds
mclloyd
bkeepers
jakevdp
sferik
myddelton
pauljervisheath
swwweet