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
220
アーキテクチャを明文化して臨んだ新規アプリ開発戦略
「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
100
Meet the Translation API
akkie76
0
340
コードレビューで開発を加速させるAIコードレビュー
akkie76
1
570
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
5k
コードレビューを支援するAI技術の応用
akkie76
5
1.1k
オブジェクト指向コードレビューの新しいアプローチ
akkie76
3
8.7k
Jetpack Compose で Adaptive Layout に対応しよう
akkie76
0
790
Observationではじめる値監視
akkie76
4
4.6k
TextField 表示スタイル変更の 有効活用例 5 選
akkie76
0
670
Other Decks in Programming
See All in Programming
カオスに立ち向かう小規模チームの装備の選択〜フルスタックTSという装備の強み _ 弱み〜/Choosing equipment for a small team facing chaos ~ Strengths and weaknesses of full-stack TS~
bitkey
1
110
Lambda(Python)の リファクタリングが好きなんです
komakichi
3
220
AWS で実現する安全な AI エージェントの作り方 〜 Bedrock Engineer の実装例を添えて 〜 / how-to-build-secure-ai-agents
gawa
8
880
Cursor/Devin全社導入の理想と現実
saitoryc
24
18k
The Implementations of Advanced LR Parser Algorithm
junk0612
1
790
これだけは知っておきたいクラス設計の基礎知識 version 2
masuda220
PRO
24
6.6k
Building Scalable Mobile Projects: Fast Builds, High Reusability and Clear Ownership
cyrilmottier
2
310
Contribute to Comunities | React Tokyo Meetup #4 LT
sasagar
0
560
AIコーディングの理想と現実
tomohisa
32
35k
プロダクト横断分析に役立つ、事前集計しないサマリーテーブル設計
hanon52_
2
480
Enterprise Web App. Development (1): Build Tool Training Ver. 5
knakagawa
1
120
Qiita Bash
mercury_dev0517
2
210
Featured
See All Featured
Practical Orchestrator
shlominoach
187
11k
The Cult of Friendly URLs
andyhume
78
6.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.4k
Raft: Consensus for Rubyists
vanstee
137
6.9k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Faster Mobile Websites
deanohume
306
31k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
19
1.2k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.5k
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.7k
Rails Girls Zürich Keynote
gr2m
94
13k
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 !