Upgrade to Pro — share decks privately, control downloads, hide ads and more …

忙しい人のためのClean Architecture

yuriemori
December 08, 2022

忙しい人のためのClean Architecture

yuriemori

December 08, 2022
Tweet

More Decks by yuriemori

Other Decks in Design

Transcript

  1. #codepolaris Clean Architecture(本)の紹介
 Robert C. Martin 色んなソフトウェア設計原則を提唱したりアジャイル開発宣言の創設に 携わった人。通称Uncle Bob Clean

    Architecutureはボブおじさんのエンジニア人生で辿り着いた ”いい感じのアーキテクチャ”とはどういうものか、って話。
  2. #codepolaris Agenda
 • チームメンバー紹介 • Clean Architectureって結局何なの? • あるあるな誤解 ◦

    Clean Architecture≠あのドーナツのアーキテクチャモデル ◦ Clean Architecture≠SOLID • Clean Architecture的に考える幸福度の高い実装 ◦ SOLIDの話 ◦ JavaのSpringフレームワークを使った SOLIDの実装(live coding)by しのさん • Agile/DevOpsから考えるClean Architecture ◦ DevOpsから考えるClean Architecture ◦ Agileとアーキテクチャ
  3. #codepolaris • Software Engineer@Avanade Jappan • C#, Azure, .Netなどなど •

    今のPJではSitecoreというCMSを使った設計、開発をやってます • Agile/DevOps • Azure DevOpsを使ったスクラムの実践やチーム開発環境の構築 ・運用をテーマに登壇したりしてます 今までの登壇資料はコチラ 森 友梨映(Yurie Mori) @1115_lilium https://www.linkedin.com/in/yurie-mori-15392a1bb/
  4. #codepolaris 自己紹介
 名前:しの • 金融系の会社でJavaエンジニア5年目 (Java大好き) • 結婚後に大学に入りなおしてエンジニアになる • 輪読会中に妊娠→育休→仕事復帰

    • あまり頑張りすぎないをモットーに、 ゆるゆるエンジニアを楽しんでいます • 趣味はボードゲーム 輪読会中の様子 生Uncle Bob
  5. #codepolaris 自己紹介
 名前:ねこさいん • 薬学生→エンジニア (予定) • 普段はPythonを使っている • 好物:お刺身とコーヒーと紅茶

    • 趣味:最近スプラ3にハマっている • 一言:クリーンアーキテクチャどころか   「オブジェクト指向なにそれおいしいの」    状態でしたが、    居心地がよかったので居座りました。 ◦ 競技プログラミング (AtCoder) ◦ 研究 (薬のもとになる物質探し ) ◦ 学生ハッカソン、ISUCON等参加
  6. #codepolaris どうしたら幸せになれる?
 開発(設計・実装)→テスト→デプロイ→リリース→運用・保守 よい設計をするための指標 ・SOLID よい実装をするための指標: ・KISS(Keep It Short, Simple)

    ・ YAGNI(Your Ain’t Going to Need It) ・ DRY(Don’t Repeat Yourserf) ・ よい命名 etc. デプロイが容易な単位に コンポーネント化されている ・再利用・リリース等価の原則 ・閉鎖性共通の原則 ・全再利用の原則 etc. ・依存関係があんまりない ・デプロイ、リリース作業自体が 簡単 ・デプロイ、リリース作業後に事 故らない ・どこを直せばいいかすぐわかる ・修正する時に他への影響範囲が少 ない ・機能追加しやすい ・テストが簡単 ・テストの範囲はできるだけ狭い 方が嬉しい ・適切にモジュール分けされている
  7. #codepolaris • ソフトウェアを開発する上で一番重要な のはビジネスルール(Entity)で、DBとか UIとかデバイス、それとビジネスロジック とのインターフェイス はソフトウェアの 「外」の要素だから、それに依存してはい けない •

    Entityとそれより外部にある要素は制御 の流れと依存関係が適切に分離されて いるべき これはEntityとそれに関係ない外部の要素 を切り分けて依存関係を分離せよ、と言って いて、この図=クリーンアーキテクチャのモ デルそのものではない
  8. #codepolaris SOLID原則
 
 項目 意味 英語 S 単一責任の原則 (SRP:Single Responsibility

    Principle) O オープン・クローズドの原則 (OCP:Open-Closed Principle) L リスコフの置換原則 (LSP:Liskov Substitution Principle) I インターフェイス分離の原則 (ISP:Interface Segregation Principle) D 依存関係逆転の原則 (DIP:Dependency Inversion Principle)
  9. #codepolaris S:単一責任の原則
 (SRP:Single Responsibility Principle)
 There should never be more

    than one reason for a class to change. (→変更するための理由が、一つのクラスに対して一つ以上あってはならない) 一つのクラスは一つの機能のみを担当する
  10. #codepolaris O:オープン・クローズドの原則 (OCP:Open-Closed Principle)
 software entities (classes, modules, functions, etc.)

    should be open for extension, but closed for modification. (→ソフトウェアの実体(クラス、モジュール、関数など)は、拡張に対して開かれている べきであり、修正に対して閉じていなければならない) ある機能の追加などがある場合、既存のコードを変更せずにその機能の追加(拡張)が 出来るように設計をするべし
  11. #codepolaris L:リスコフの置換原則 
 (LSP:Liskov Substitution Principle)
 Functions that use pointers

    or references to base classes must be able to use objects of derived classes without knowing it. (→ある親クラスへのポインタないし参照を扱っている関数群は、その子クラスのオブ ジェクトの詳細を知らなくても扱えるようにしなければならない) サブタイプ(S)とスーパータイプ(T)は「S is a T」の原則にのっとり、置換可能である
  12. #codepolaris I:インターフェイス分離の原則
 (ISP:Interface Segregation Principle)
 Many client-specific interfaces are better

    than one general-purpose interface. (→汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェース がたくさんあった方がよい) クライアントが、自分の必要な要素だけを継承できるするようにするべき 一つのインターフェースに沢山の要素が入っていると、あるクライエントにとっては必要 のないものが継承されるということが起きるから
  13. #codepolaris D:依存関係逆転の原則
 (DIP:Dependency Inversion Principle)
 High-level modules should not import

    anything from low-level modules. Both should depend on abstractions (e.g., interfaces), [not] concretions. (→上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方と も具象ではなく、抽象(インターフェースなど)に依存するべきである) 外側のクラスが内側のクラスに依存するようなことはしてはいけない (インターフェースを経由すると、依存関係を断ち切ることが出来るのでこの本で推奨さ れているが、アノテーションを使うことでも回避できる)
  14. #codepolaris 今回のテーマ
 1. アカウントの開設 ◦ 違うタイプのアカウントが開設できる 2. 預金 ◦ BankCode,BankBranch,

    AccountNumberでアカウントの特定をする ◦ 預金できるアカウントとできないアカウントがある ▪ BasicAccountとSavingAccountは預金ができる ▪ SuperSavingAccountは預金が出来ない オンライン銀行口座サイトを実装せよ!
  15. #codepolaris どんなデザインパターンを使う?
 ❖ DTO (Data Transfer Object) とVO (Value Object)

    ➢ データ受け渡しの為のクラス ➢ DTOがエコバッグ的な存在、 VOが段ボールで蓋された荷物的な存在 ❖ Factory Pattern ➢ フレキシブルにインスタンスの生成をするためのデザインパターン ➢ インスタンスの生成をファクトリー (=工場)に任せる ❖ Builder Pattern ➢ インスタンスの生成をコンストラクターに頼らずに出来る ➢ 将来attributeが増えていっても、今あるインスタンス生成の為のコードは壊れずに使える
  16. #codepolaris Controllerで使われるannotation
 Controllerは外部との接続を担当 リクエストを受け取って、レスポンスを返す (基本はクラスをJSONに変換したものが返さ れる) ❖ @Controller, @RestController ➢

    そのクラスはWebサービスになり、外部との接続を行う ❖ @RequestMapping(“/bankAccount”) ➢ http://localhost:8080/bankAccount で接続が出来るようになる ❖ @PostMapping, @GetMapping, @PutMapping etc… ➢ RequestMappingの、http メソッドを指定
  17. #codepolaris 各クラスの役割
 • BankAccount ◦ BasicAccount や SavingAccount の親クラス •

    BankAccountRepository (@Repository) ◦ DBへの接続 • BankAccountController (@Controller) ◦ 外部への接続 • BankAccountService (@Service) ◦ ビジネスロジック (仲介業者的な)
  18. #codepolaris 今回のテーマ
 1. アカウントの開設 ◦ 違うタイプのアカウントが開設できる 2. 預金 ◦ BankCode,BankBranch,

    AccountNumberでアカウントの特定をする ◦ 預金できるアカウントとできないアカウントがある ▪ BasicAccountとSavingAccountは預金ができる ▪ SuperSavingAccountは預金が出来ない オンライン銀行口座サイトを実装せよ!
  19. #codepolaris 復習
 ❖ BankAccount とBasicAccount, SavingAccountは置換可能である ➢ リスコフの置換原則 ❖ Repository,

    Controller, Service, Factory などでそれぞれ一つのことを担当 ➢ 単一責任の原則 ❖ Depositableを継承するのはdepositのメソッドが必要なクラスのみ ➢ インターフェース分離の原則 ❖ FactoryやBuilderのデザインパターン ➢ オープンクローズドの原則 ❖ @Autowiredを使って、上位モジュールでの直接のインスタンス生成を避ける ➢ 依存性逆転の原則
  20. #codepolaris 思い出して、アーキテクチャとは?アーキテクチャの目的は?
 • アーキテクチャの主な目的は、 システムのライフタイムをサポートすること である。優れたアーキテクチャ があれば、システムを容易に理解・開発・保守・デプロイできる。 • 作ったら(開発が終わったら) デプロイして、リリースして、リリースした後もちゃんと動くようにしないといけ

    ない(保守)、必要であれば、機能を追加してアップデートしたり修正 しないといけない(運用) クラス(ソースコードレベルでのモジュール)< コンポーネント(デプロイの単位。.Netのdll, Javaの.jar)< アーキテクチャ ソフトウェアの人生:開発(設計・実装) →テスト→デプロイ→リリース→運用・保守 ・開発した後もデプロイ、リリース、運用、保守がしやすければソフトウェアの人生全体をサポートできる ・では、デプロイ、リリース、運用、保守のしやすさはどうやって達成できる? →その鍵はコンポーネント(デプロイの単位)
  21. #codepolaris まとめ
 • 見通しができる小さい単位に分割して、DoDやAcceptance Criteriaを満たすように 作っていく。 • 最初はアーキテクチャの構成の最小の単位(クラス・モジュール)をSOLIDの原則 に沿うように作る(最小の部品をちゃんと作る) •

    作ったものは継続的にテストをして、常にリリース可能な状態にする • 最小の部品(クラス)を作る→それを組み合わせてコンポーネントを作る という流 れをsprintを重ねて作っていく • それを繰り返すとアーキテクチャが”現れる”(Emergent Architecture :創発的アー キテクチャ)
  22. #codepolaris References
 • Clean Architecture 達人に学ぶソフトウェアの構造と設計 https://amzn.asia/d/fPVihGj • プリンシプル オブ

    プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 P13. よい実装をするための指標 (KISS, YAGNI, DRYについて書かれてる) https://amzn.asia/d/7hydTCq • DevOpsとアジャイルの比較 P35. ソフトウェアの人生と DevOps https://azure.microsoft.com/ja-jp/overview/devops-vs-agile/ • アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技 P44- Agileとアーキテクチャ https://amzn.asia/d/cudAF5n • Emergent Architecture: Architecture in the Age of Agile P50. アジャイルの経験主義と創発的アーキテクチャ  https://medium.com/@steve.cornish/emergent-architecture-architecture-in-the-age-of-agile-9f21ba654845