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
230
アーキテクチャを明文化して臨んだ新規アプリ開発戦略
「After DroidKaigi LT Night」2023/09/25の登壇資料です。
akkiee76
September 26, 2023
Tweet
Share
More Decks by akkiee76
See All by akkiee76
Graph Art with Charts API – Beyond Data Visualization
akkie76
0
170
Meet the Translation API
akkie76
0
420
コードレビューで開発を加速させるAIコードレビュー
akkie76
1
670
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
6k
コードレビューを支援するAI技術の応用
akkie76
5
1.2k
オブジェクト指向コードレビューの新しいアプローチ
akkie76
3
9.3k
Jetpack Compose で Adaptive Layout に対応しよう
akkie76
0
1k
Observationではじめる値監視
akkie76
4
4.7k
TextField 表示スタイル変更の 有効活用例 5 選
akkie76
0
730
Other Decks in Programming
See All in Programming
技術的負債の正体を知って向き合う
irof
0
230
Things You Thought You Didn’t Need To Care About That Have a Big Impact On Your Job
hollycummins
0
250
NixOS + Kubernetesで構築する自宅サーバーのすべて
ichi_h3
0
1.1k
AkarengaLT vol.38
hashimoto_kei
1
110
登壇は dynamic! な営みである / speech is dynamic
da1chi
0
350
実践Claude Code:20の失敗から学ぶAIペアプログラミング
takedatakashi
16
6.6k
AI Agent 時代的開發者生存指南
eddie
4
2.1k
品質ワークショップをやってみた
nealle
0
600
EMこそClaude Codeでコード調査しよう
shibayu36
0
320
コードとあなたと私の距離 / The Distance Between Code, You, and I
hiro_y
0
190
Writing Better Go: Lessons from 10 Code Reviews
konradreiche
3
5.7k
Vueのバリデーション、結局どれを選べばいい? ― 自作バリデーションの限界と、脱却までの道のり ― / Which Vue Validation Library Should We Really Use? The Limits of Self-Made Validation and How I Finally Moved On
neginasu
1
150
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
31
9.7k
Making Projects Easy
brettharned
120
6.4k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.6k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
130k
Embracing the Ebb and Flow
colly
88
4.9k
GitHub's CSS Performance
jonrohan
1032
470k
Site-Speed That Sticks
csswizardry
13
920
Speed Design
sergeychernyshev
32
1.2k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
55
3k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
BBQ
matthewcrist
89
9.8k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.5k
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 !