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

Transcript

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