Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
アーキテクチャを明文化して臨んだ新規アプリ開発戦略
Search
akkiee76
September 26, 2023
Programming
0
140
アーキテクチャを明文化して臨んだ新規アプリ開発戦略
「After DroidKaigi LT Night」2023/09/25の登壇資料です。
akkiee76
September 26, 2023
Tweet
Share
More Decks by akkiee76
See All by akkiee76
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
200
コードレビューを支援するAI技術の応用
akkie76
5
460
オブジェクト指向コードレビューの新しいアプローチ
akkie76
3
6.4k
Jetpack Compose で Adaptive Layout に対応しよう
akkie76
0
120
Observationではじめる値監視
akkie76
3
1.9k
TextField 表示スタイル変更の 有効活用例 5 選
akkie76
0
310
rememberUpdatedState の使いどころを考える
akkie76
0
200
M3 NavigationBar をマスターする
akkie76
0
490
プライバシー強化の最前線 ~2024年春以降の展望と対策~
akkie76
0
160
Other Decks in Programming
See All in Programming
Behind VS Code Extensions for JavaScript / TypeScript Linnting and Formatting
unvalley
6
1.3k
業務ツールとして使うPostman
msys75
0
120
Anthropic Cookbook のおすすめレシピ
schroneko
7
1.4k
Apache Hive 4 on Treasure Data
ryukobayashi
1
460
slow types ってなんだろう?
karad
0
190
新宿ダンジョンを可視化してみた
satoshi7190
3
420
Let's learn code review
riofujimon
2
620
CREってこういうこと? 体験入社 - 提案資料 - / what-is-cre-trial-employment
shinden
1
580
GitLab CI/CD で C#/WPFアプリケーションのテストとインストーラーのビルド・デプロイを自動化する
hacarus
0
520
障害対応を起点としたもっといい開発と運用のサイクル作りのためにできること / Hatena Enginner Seminar #29
polamjag
0
430
Open AI APIを使う前に知っておきたいアカウントTier の話
akki_megane
0
110
AWS CDKコントリビュートTIPS / aws-cdk-contribution-tips
gotok365
4
560
Featured
See All Featured
Intergalactic Javascript Robots from Outer Space
tanoku
266
26k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
221
21k
Imperfection Machines: The Place of Print at Facebook
scottboms
261
12k
Producing Creativity
orderedlist
PRO
338
39k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
51k
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Raft: Consensus for Rubyists
vanstee
133
6.3k
Rails Girls Zürich Keynote
gr2m
91
13k
Teambox: Starting and Learning
jrom
128
8.4k
The Invisible Customer
myddelton
114
12k
Debugging Ruby Performance
tmm1
70
11k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
21
1.6k
Transcript
©2023 RAKUS Co., Ltd. アーキテクチャを明文化して臨んだ 新規アプリ開発戦略 After DroidKaigi LT Night
2023/09/25 @akkiee76
Akihiko Sato 株式会社ラクス 楽楽精算開発 iOS / Android / バックエンド @akkiee76
自己紹介
既存アプリのリプレース案件で 実際に行なった開発戦略 😃
リプレースの背景 弊社1アプリのフレームワークとして Cordova を使用 • Cordova Android の開発が遅延 ◦ 新バージョン、API
への対応の遅れ • Cordova 自体の EOL リスク ネイティブアプリとしてリプレースすることに
開発に向けてのチーム課題 • Android ネイティブアプリのナレッジが少ない • 新規アプリ開発の経験がない リプレース案件の苦戦が明らか・・・ 😕
アーキテクチャを確立し ガイドラインとして明文化しよう😃
アーキテクチャ選定にあたって • モダンなアーキテクチャは学習コストが大きい • 開発のスケジュールもタイト オーソドックスな MVVM アーキテクチャを採用 (Compose の採用は見送りに)
https://developer.android.com/jetpack/guide
設計の基本原則 ガイドライン作成にあって以下を基本原則に • 「関心の分離(単一責任の原則)」を重要原則とする • クラスの責務をできるだけシンプル/コンパクトに保つ • 責務の細分化により、テスト容易性を向上させる
では、明文化した内容を一部紹介します😃
レイヤー構造 3層レイヤー構造を採用し定義を記載 • Presentation Layer • Domain Layer • Data
Layer https://developer.android.com/jetpack/guide
Presentation Layer の定義 プレゼンテーション層は、ユーザーに情報を表示し、入力を受け付ける機能を 持っています。具体的には、ユーザー操作や外部入力(レスポンス)によって データが変更されるたびに、変更された情報を反映するよう UI を更新する必要 があります。 主にプレゼンテーション層は、Activity、Fragment、ViewModel
や BindingModel に変換するための Converter などを配置します。また、 RecyclerView を用いる場合、 Adapter や ViewHolder などもプレゼンテーショ ン層に配置します。
Domain Layer の定義 ドメイン層は、複雑なビジネスロジックや複数の ViewModel で再利用される単 純なビジネスロジックが隠蔽(カプセル化)されたレイヤーです。 ビジネスロジックの複雑さに対処する場合や再利用性を優先する場合、対象の ロジックをこのレイヤーに実装します。また、各ユースケースでは異なるビジネ スロジックが集約されるため、それぞれのユースケースクラスは疎であることが
アーキテクチャとして重要です。
Data Layer の定義 データ層は、アプリで扱うデータに関連するロジックが集約されます。具体的に は、アプリで使用するデータの作成、保存、変更方法(APIに関するものを含 む)を決定する実際のロジックで構成されることがこのレイヤーの期待です。 データ層は、それぞれが 0 から複数のデータソースを含むことができるリポジト リで構成されます。また、アプリで処理するデータの種類ごとに
Repository を 作成する必要があります。
Package 構成を定義
基本クラスの各ルールを記載 ・Activity ・Fragment ・ViewModel ・UseCase ・Repository ・責務 ・命名規則 ・ルール(制約) ・実装例
・テストで確認すること ・テスト実装例 明文化 各ルールを適用したサンプルプロジェクトも用意
開発完了後に 振り返ってみると・・・
良かったこと ✅ チームの技術力が向上 ・オブジェクト指向の成長 ✅ 設計の議論をすることが少なく、開発に注力できた ・チームの生産性が 20% 向上 ✅
クラスの責務を小さくしたため、テストが実装しやすかった ・テスト品質の担保
イマイチだったこと 🚫 アプリ規模に対してファイル数が多くなる ・責務を細かく分けすぎてしまった 🚫 メンバーにより理解度の乖離が出てしまった ・ガイドラインを作成しても実践するための学習コストは必要 🚫 package 構成を各レイヤーで限定しすぎてしまった
・レイヤーを跨いで使用するクラスの置き場に困る(後述)
package 構成の技術的課題 「NetworkError」のようにレイヤーを跨いで使用するクラスが複数登場 package private が望ましい
課題へのアプローチ • アプリ本体はドメイン駆動の package 構造に変更 • マルチモジュールを採用し、どのドメインからも参照可能に
まとめ アーキテクチャの明文化により以下の恩恵を受けることができます • チームの技術力向上 • 開発の生産性アップ • 品質担保 チームでぜひトライしてみてはいかがでしょうか
Thank you !