ランチタイムLT会 #1（2023年6月5日）での発表資料です。
何故、UseCaseは1メソッドなのか
View Slide
話す人• 奥澤 @okuzawats• Chatwork株式会社 •ビジネスチャットChatwork Android版のアーキテクチャ改善業、技術負債返済業をやっています。 •Kotlinで `operator fun get` を書くチャンスを虎視眈々と狙っています🐯
Software Design 2023年6月号の特集、「クリーンアーキテクチャとは何か？」は読みましたか？
今日はこの特集の5章「モバイルアプリ開発における実践」を執筆した後で、同僚から受けたコメントに答えていこうと思います。
UseCase
しばしば見るUseCase
👆1つの画面に対して1つのUseCase型を作って、そこに複数のメソッドが定義されるパターン
一方、Androidのアプリアーキテクチャガイドでは👇
アプリアーキテクチャガイドの示すUseCaseUseCaseの担うアクションに基づいた命名動詞 ＋ 名詞 / 対象 ＋ UseCase`LogoutUserUseCase`operator修飾子を使用して `invoke()` 関数を定義することでUseCaseのインスタンスを関数として呼び出す`logoutUserUseCase()`👉このルールに従うと必然的に1 UseCase - 1 (public) メソッドになる。
1 UseCase 1 (public) mehtodで嬉しいことUseCaseの担うアクションの再利用性が高まる複数の画面からログアウト処理を呼び出す場合、複数の画面でLogoutUserUseCaseを使えば良い。最初に出てきたSomeUseCaseのfunctionを再利用しようとすると…？UseCaseの保守性が高まる（凝集度が高まる）1クラスに書かれる処理が、ただひとつのアクションに関連する処理だけになる。テストコードも読みやすい。
ઌ΄ͲͷྫΛॻ͖͢ͱ͜Μͳײ͡ʹͳΔ
1 UseCase - 1 (public) メソッドのメリットUseCaseの担うアクションの再利用性が高まるUseCaseの保守性が高まる（凝集度が高まる）
1 UseCase - 1 (public) メソッドのデメリットUseCaseのアクションが再利用されない場合、ただ面倒くさい何らかのアクションを追加するたび、UseCaseのinterfaceを作って、実装クラスを作って、テストクラスを作って、Hiltのモジュールを作って…という「面倒くささ」のコストを正当化しにくい
こっちのパターンが絶対にダメとまでは言いにくい🤔
まとめUseCaseは、1 UseCase - 1メソッドで作れると嬉しい🤗実装クラス、テストクラスが圧倒的に美しい✨（個人の感想）UseCaseが再利用されない場合、面倒くささが勝ちがち😅「これ面倒くさくないですか？」って言われたらそれまで
最後にChatworkでは、Android アプリエンジニアを募集しています！（それ以外の職種も絶賛募集中です！）
参考文献Software Design 2023年6月号, 技術評論社Android Developer, ドメインレイヤ, retrieved from https://developer.android.com/jetpack/guide/domain-layer?hl=ja （最終アクセス日：2023年5月27日）松岡幸一郎, (2020), ドメイン駆動設計 モデリング/実践ガイド
okuzawats
mochico
yellowshippo
gawa
koudaiii
keio_smilab
miyake
imsaku
masakamayama
pauli
bonotake
brainpadpr
nagix
bluesmoon
marktimemedia
andyhume
jensimmons
thoeni
danielanewman
tammielis
malarkey
sachag
reverentgeek
mza