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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

はじめに

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

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

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

安定性の議論

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

＜疑問＞プログラムの全部がまんべんなく「ソフト」であるべきなのか？

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

実線：依存方向　点線：処理の流れ

Slide 27

Slide 27 text

詳細が方針に依存するようにせよ（逆はダメ）

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

Unityと結婚するな（最後に小噺的な）

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

おわりに

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

参考文献 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/