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

そろそろ軽率に クリーンアーキテクチャ(な思考) の話がしたくて / i want to talk about a think of clean architecture thoughtlessly

そろそろ軽率に クリーンアーキテクチャ(な思考) の話がしたくて / i want to talk about a think of clean architecture thoughtlessly

にー兄さん

January 22, 2023
Tweet

More Decks by にー兄さん

Other Decks in Programming

Transcript

  1. そろそろ軽率に
    クリーンアーキテクチャ(な思考)
    の話がしたくて
    IwakenLab設計座談会
    にー兄さん(@ninisan_drumath)

    View Slide

  2. 発表資料は公開します👍
    スクショ等のSNS共有OKです📸

    View Slide

  3. にー兄さん(@ninisan_drumath)
    自称Unity・ARエンジニア
    ロケーションベースAR / Unity / WebAR /
    Babylon.js / Azure Kinect
    最新技術を使ったデモンストレーションが好き
    - 筑波大学 情報科学類
    - 株式会社ホロラボ アルバイト
    - Microsoft 学生アンバサダー
    - Iwaken Lab

    View Slide

  4. アジェンダ
    - はじめに
    - ”ソフト”ウェアについて考える
    - 安定性の議論
    - Unityと結婚するな!
    - おわりに

    View Slide

  5. はじめに

    View Slide

  6. 本発表のゴール
    変更に柔軟なソフトウェア開発の考え方を理解する
    Clean Architecture本を読む足掛かりを作る

    View Slide

  7. 本発表のターゲット
    - (Unity開発者)
    - 参加者にUnity経験者が多いため便宜上
    - 設計原則への理解がある / 理解にチャレンジしている
    - 大規模ソフトウェア開発に興味がある
    - (クリーン)アーキテクチャという言葉は知ってる

    View Slide

  8. 所感
    CAの概念を理解するのはeasyではない
    普遍的なソフトウェア開発の知識であるため抽象度高め
    OOPやSOLID原則の理解の上にある
    あえて「あの図」は出さないことに(雑談フェーズで出すかも)
    「あの図」から生まれる誤解を10分で解くのは難しいため
    加えて実現するのも結構難しい(という理解をしている)
    CAは理想形にすぎないが、理想形を知ることはとても重要である
    根拠のある妥協をしよう

    View Slide

  9. 諸注意・免責
    私自身は大規模開発の経験は少ないため、「頭でっかち」な部分があります
    実際の現場では適切にアーキテクチャを選択する必要がありますが
    本発表ではあくまで「理想論」という受け止め方をしてください
    マサカリは研がない・投げない・振り回さない
    本発表内容によって被った損害・損失については一切の責任を負いかねます。
    ご了承ください。

    View Slide

  10. ”ソフト”ウェアについて考える

    View Slide

  11. 何がソフトウェアを「ソフト」たらしめるのか

    View Slide

  12. 何がソフトウェアを「ソフト」たらしめるのか
    変更の柔軟性
    ハードウェアは容易に変更できない
    ソフトウェアは容易に変更できる

    View Slide

  13. なんで変更するのか、そもそも変更とは何か
    理由・モチベ
    - 新機能の追加の要望
    - バグの修正
    - ライブラリのアップデート
    - リファクタリング
    - パフォーマンス向上
    内容
    - ページ(UI)の追加
    - 採用ライブラリの変更
    - 新規デバイスの対応実装
    - データベース設計の変更
    変更の理由や内容は様々

    View Slide

  14. 長く続くソフトウェアの運用
    ソフトウェアは生き物である(生まれ、成長し、死ぬ)
    寿命を長くするためには長期的なメンテナンスが不可欠
    しかしソフトウェアは機能を追加すればするほど
    メンテナンスコストが上がっていく
    機能間で無駄な依存関係がある
    →一つの変更理由でいくつも機能変更が生じる
    →避けたい事態
    設計によって、変更に強い”ソフト”ウェアを作ろう!

    View Slide

  15. 安定性の議論

    View Slide

  16. プログラムの基本は入力と出力
    プログラムの基本形は
    入力を受け取り出力を返す
    大きなプログラムになっても
    入出力の集合になっている
    例えばユーザの入力を受け取
    り、画面に出力したりデータベー
    スに出力したり

    View Slide

  17. 内部的には複数のプログラムを経由することになる

    View Slide

  18. <疑問>
    プログラムの全部がまんべんなく
    「ソフト」であるべきなのか?

    View Slide

  19. A. 柔軟な部分とそうでない部分があってよい
    プログラムのすべてが変更される可能性は極めて低い
    (それはもはや別サービス)
    つまりビジネスロジックは変更されにくい
    逆に変更されやすい部分
    - ボタンの色や形
    - ページやメニューの種類
    - 対応デバイス
    - 外部API
    - DBMSの種類

    View Slide

  20. 安定部分と柔軟部分は分けて考える
    ビジネスロジック 見た目やデータストア
    安定 柔軟
    上位モジュール 下位モジュール
    方針 詳細

    View Slide

  21. 一応依存方向について復習

    View Slide

  22. 処理の流れと依存方向は?
    new A();
    class A
    {
    public A() { new B(); }
    }
    class B
    {
    public B() { new C(); }
    }
    class C { }

    View Slide

  23. 処理の流れ 依存方向
    A
    C
    B
    AがBを呼ぶ
    BがCを呼ぶ
    A
    C
    B
    AがBに依存
    BがCに依存

    View Slide

  24. 処理の流れと依存方向について
    <愚直な実装>
    一番最後の出力ロジックに
    ドメインロジックが依存する
    下位モジュールは不安定だから依
    存したくない
    DIPにのっとり、依存方向を逆転さ
    せる

    View Slide

  25. 依存方向
    A
    C
    B
    AがBに依存
    BがCに依存
    依存方向
    A
    C
    B
    AがBに依存
    CがICを実装
    B名前空間に依存
    IC
    DIP
    BがICに依存

    View Slide

  26. 実線:依存方向 点線:処理の流れ

    View Slide

  27. 詳細が方針に
    依存するようにせよ
    (逆はダメ)

    View Slide

  28. モジュールの境界で
    依存方向を適切に制御
    せよ

    View Slide

  29. Unityと結婚するな
    (最後に小噺的な)

    View Slide

  30. 詳細について知ろう
    ここでいうUnityとは詳細のこと
    RailsもASP.NETもReact/Vueも
    MySQLもFirebaseもSupabaseも
    HoloLensもQuest Proも

    View Slide

  31. 詳細と結婚しないメリット
    1. 詳細を差し替えられる
    2. 詳細の意思決定を遅延できる

    View Slide

  32. しかし、あなたは詳細は求婚されている
    フレームワークは依存を迫ってくる
    「私の抽象クラスを継承して♡」
    渋い顔をしながら断るか、適切な根拠を持って結婚するか

    View Slide

  33. おわりに

    View Slide

  34. まとめ
    クリーンアーキテクチャの考え方
    - 詳細が方針に依存するように
    - そのためにモジュール境界で適切に依存関係を制御せよ
    これをどこまでしっかりやるか
    見極められるようになりたい

    View Slide

  35. 参考文献
    Clean Architecture 達人に学ぶソフトウェアの構造と設計
    https://www.amazon.co.jp/Clean-Architecture-%E9%81%94%E4%BA%BA%E3%81%AB%E5%AD%A6%E3%81%B6%E3%82%BD%
    E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E3%81%AE%E6%A7%8B%E9%80%A0%E3%81%A8%E8%A8
    %AD%E8%A8%88-Robert-C-Martin/dp/4048930656
    世界一わかりやすい Clean Architecture
    https://www.nuits.jp/entry/easiest-clean-architecture-2019-09
    クリーンアーキテクチャ完全に理解した
    https://gist.github.com/mpppk/609d592f25cab9312654b39f1b357c60
    実装クリーンアーキテクチャ
    https://qiita.com/nrslib/items/a5f902c4defc83bd46b8
    clean architecture と asmdef - 【年末だよ】Unity お・と・なのLT大会 2019
    https://www.youtube.com/watch?v=PdYeUu2-gOU
    Clean Architecture for Unity
    https://learning.unity3d.jp/4021/

    View Slide