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
190
アーキテクチャを明文化して臨んだ新規アプリ開発戦略
「After DroidKaigi LT Night」2023/09/25の登壇資料です。
akkiee76
September 26, 2023
Tweet
Share
More Decks by akkiee76
See All by akkiee76
Meet the Translation API
akkie76
0
230
コードレビューで開発を加速させるAIコードレビュー
akkie76
1
360
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
2.9k
コードレビューを支援するAI技術の応用
akkie76
5
720
オブジェクト指向コードレビューの新しいアプローチ
akkie76
3
7.7k
Jetpack Compose で Adaptive Layout に対応しよう
akkie76
0
520
Observationではじめる値監視
akkie76
4
4.4k
TextField 表示スタイル変更の 有効活用例 5 選
akkie76
0
530
rememberUpdatedState の使いどころを考える
akkie76
0
370
Other Decks in Programming
See All in Programming
推し活としてのrails new/oshikatsu_ha_iizo
sakahukamaki
3
1.3k
gopls を改造したら開発生産性が高まった
satorunooshie
8
230
cXML という電子商取引の トランザクションを支える プロトコルと向きあっている話
phigasui
2
2k
Synchronizationを支える技術
s_shimotori
1
140
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
100
約9000個の自動テストの 時間を50分->10分に短縮 Flakyテストを1%以下に抑えた話
hatsu38
21
9.8k
讓數據說話:用 Python、Prometheus 和 Grafana 講故事
eddie
0
330
[PyCon Korea 2024 Keynote] 커뮤니티와 파이썬, 그리고 우리
beomi
0
110
Importmapを使ったJavaScriptの 読み込みとブラウザアドオンの影響
swamp09
3
1.2k
CSC509 Lecture 07
javiergs
PRO
0
140
Vue.js学習の振り返り
hiro_xre
2
130
Honoの来た道とこれから
yusukebe
19
3k
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1030
460k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.6k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Six Lessons from altMBA
skipperchong
26
3.4k
Building Applications with DynamoDB
mza
90
6k
Code Reviewing Like a Champion
maltzj
519
39k
Statistics for Hackers
jakevdp
796
220k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
225
22k
Code Review Best Practice
trishagee
64
17k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
504
140k
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 !