クリーンアーキテクチャを活かす考察

by kanayannet

Slide 1

Slide 1 text

Gunma.web #43 Gunma.web #43 クリーンアーキテクチャを活かす考察クリーンアーキテクチャを活かす考察 @kanayannet

Slide 2

Slide 2 text

Agenda Agenda なぜ、やろうと思ったのか？考察活かし方まとめ

Slide 3

Slide 3 text

なぜ、やろうと思ったのか？なぜ、やろうと思ったのか？

Slide 4

Slide 4 text

チームリーダとして作業の割り振りを考える

Slide 5

Slide 5 text

依存関係の切り方をしっかりやらないと.. 各担当者間でやり直しが多くなる理由は... 後述で出します。

Slide 6

Slide 6 text

依存関係をしっかりと切れれば... 各担当者がハッピー deploy までスムーズ

Slide 7

Slide 7 text

そんな事を考えていると .. そんな事を考えていると .. クリーンアーキテクチャに遭遇クリーンアーキテクチャに遭遇

Slide 8

Slide 8 text

この本ですねこの本ですね

Slide 9

Slide 9 text

アーキテクチャのルールはアーキテクチャのルールはどれも同じであるどれも同じである

Slide 10

Slide 10 text

アーキテクチャのルールはアーキテクチャのルールはどれも同じであるどれも同じである繰り返し大事なのでリピート

Slide 11

Slide 11 text

何がどう同じなのか？何がどう同じなのか？話していきたいと思います。話していきたいと思います。

Slide 12

Slide 12 text

考察考察

Slide 13

Slide 13 text

この本実は ... この本実は ...

Slide 14

Slide 14 text

とにかく前振りが長い！とにかく前振りが長い！

Slide 15

Slide 15 text

どのくらい長いのかというと ... どのくらい長いのかというと ...

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

「 22 章」＼ (^o^) ／「 22 章」＼ (^o^) ／一体 21 章までは何を ... 一体 21 章までは何を ...

Slide 18

Slide 18 text

前振りが結構重要部分前振りが結構重要部分

Slide 19

Slide 19 text

結論だけ聞いても「 ??? 」結論だけ聞いても「 ??? 」

Slide 20

Slide 20 text

前振りの中で印象深いものを前振りの中で印象深いものをいくつか話していきます。いくつか話していきます。すなわち、どのアーキテクチャにも共通する事

Slide 21

Slide 21 text

アーキテクチャの重要性アーキテクチャの重要性変更コストによって計測できるそもそも「変更のない開発」ってあるの？初めに作ったものが「絶対」なんてのは... 少なくとも自分は経験ない by @kanayannet

Slide 22

Slide 22 text

設計とアーキテクチャに設計とアーキテクチャに何も違いはない何も違いはない概要だろうが詳細だろうが、設計でありアーキテクチャであるよく分けて考える人がいるが... この本では「何も違いはない」と断言している

Slide 23

Slide 23 text

UI, ビジネスルール , DB アクセス UI, ビジネスルール , DB アクセスビジネスルールは独立させる事が可能それだけでリリースも可能 DB やUI とは別のチームが開発可能

Slide 24

Slide 24 text

ソフトウェアの振るまいソフトウェアの振るまい簡単に振る舞いを変更できるためソフト振る舞いを変更できないものハード( ウェア) と呼んだ既存の成果物を変更せず拡張できるようにすべき

Slide 25

Slide 25 text

SRP SRP 単一責任の原則モジュールはたったひとつのアクターに対して責務を負うべき単一の修正が一つだけではなく複数の修正を誘発してしまうのは違反

Slide 26

Slide 26 text

OCP OCP オープンクローズドの原則拡張に対しては開き、修正に対しては閉じてなくてはならない既存の成果物を変更せず拡張できるようにすべき

Slide 27

Slide 27 text

変化しやすい具象クラスを参照しない変化しやすい具象クラスを参照しない変化しやすいクラスを継承すると変化のたびに変更が必要になる危険性があがる

Slide 28

Slide 28 text

循環依存は厄介循環依存は厄介あるコンポーネントの変更が依存関係を循環し、自身にも悪影響を与えてしまう

Slide 29

Slide 29 text

コンポーネント図コンポーネント図循環依存恐ければ図にしてみると良い

Slide 30

Slide 30 text

依存関係逆転依存関係逆転参照元と先を変更する事で循環依存を避けられる

Slide 31

Slide 31 text

.... もっと色々あるが ... .... もっと色々あるが ... そろそろ本題に入ります。そろそろ本題に入ります。詳しくはみなさんも是非読んでみて..

Slide 32

Slide 32 text

Clean Architecture Clean Architecture

Slide 33

Slide 33 text

エンティティエンティティビジネスを表すものとして独立させるこれがないとビジネスとして成立しない最低限の単位

Slide 34

Slide 34 text

ユースケースユースケース自動化されたシステムを使用する方法を記述したものアプリケーション固有のビジネスルールを記述する入力データを加工し適切なエンティティへの参照を実現する

Slide 35

Slide 35 text

この二つの依存関係この二つの依存関係エンティティは自身を制御するユースケースのことを知らない。エンティティもユースケースも通信手段やDB やフレームワークの事は知らないそのくらい独立させておく( 汎用性を持たせる) DB, http, その他外的要素がなくともテストできる

Slide 36

Slide 36 text

フレームワーク非依存フレームワーク非依存フレームワーク依存をなくす事でツールとして利用する

Slide 37

Slide 37 text

UI 非依存 UI 非依存ビジネスルールの変更なしに変更できる http 経由 -> コンソールUI にするなど

Slide 38

Slide 38 text

外部エージェント依存外部エージェント依存ビジネルルールは外界のIF を知らないブラウザ経由 -> アプリにする際に変更がない

Slide 39

Slide 39 text

活かし方活かし方

Slide 40

Slide 40 text

頭の体操頭の体操 DB, コード設計も含みます

Slide 41

Slide 41 text

どんな頭の使い方？どんな頭の使い方？知らない = 無保証ではなく... 知らなくても動くようにするつまり依存をなくす方法を考える

Slide 42

Slide 42 text

一番大事なのは ... 一番大事なのは ... ビジネスを実現ビジネスロジックやビジネスルールと言われている箇所これを middleware で縛らない

Slide 43

Slide 43 text

コンポーネント図コンポーネント図絵にすると... 循環依存に気付きやすいよね？

Slide 44

Slide 44 text

これ RDB の外部キーでもこれ RDB の外部キーでも同じ事だよね？同じ事だよね？外部キーで循環依存は運用していくと厳しくなりそう。

Slide 45

Slide 45 text

難しいな ... 難しいな ... controller と web framework どう切り離せる?

Slide 46

Slide 46 text

とはいえ ... とはいえ ... ビジネスルールは切り離せそうここ大事

Slide 47

Slide 47 text

まとめまとめ

Slide 48

Slide 48 text

web framework controller 部分は結構結合している... 切り離し方知ってる人いる?

Slide 49

Slide 49 text

依存関係を整理していれば... ビジネスルールの分離はやれてる箇所はありそうとはいえ今後は意識したい

Slide 50

Slide 50 text

図や絵にする事大事他の人と共有するときも -> 情報非対称性対策自分も気付きやすい

Slide 51

Slide 51 text

参考参考読んでいただければ、もっと色々と解ります。

Slide 52

Slide 52 text

ご清聴ご清聴ありがとうありがとうございましたございました