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
June 22, 2022
Technology
0
970
アーキテクチャを明文化して開発に臨んだ話
akkiee76
June 22, 2022
Tweet
Share
More Decks by akkiee76
See All by akkiee76
Graph Art with Charts API – Beyond Data Visualization
akkie76
0
140
Meet the Translation API
akkie76
0
380
コードレビューで開発を加速させるAIコードレビュー
akkie76
1
610
Android Target SDK 35 (Android 15) 対応の概要
akkie76
0
5.5k
コードレビューを支援するAI技術の応用
akkie76
5
1.1k
オブジェクト指向コードレビューの新しいアプローチ
akkie76
3
9k
Jetpack Compose で Adaptive Layout に対応しよう
akkie76
0
890
Observationではじめる値監視
akkie76
4
4.6k
TextField 表示スタイル変更の 有効活用例 5 選
akkie76
0
690
Other Decks in Technology
See All in Technology
mrubyと micro-ROSが繋ぐロボットの世界
kishima
2
380
OPENLOGI Company Profile for engineer
hr01
1
33k
How Community Opened Global Doors
hiroramos4
PRO
1
130
AI専用のリンターを作る #yumemi_patch
bengo4com
4
2k
生まれ変わった AWS Security Hub (Preview) を紹介 #reInforce_osaka / reInforce New Security Hub
masahirokawahara
0
370
なぜ私はいま、ここにいるのか? #もがく中堅デザイナー #プロダクトデザイナー
bengo4com
0
1.3k
Snowflake Summit 2025全体振り返り / Snowflake Summit 2025 Overall Review
mtpooh
2
440
ドメイン特化なCLIPモデルとデータセットの紹介
tattaka
1
470
SpringBoot x TestContainerで実現するポータブル自動結合テスト
demaecan
0
120
CursorによるPMO業務の代替 / Automating PMO Tasks with Cursor
motoyoshi_kakaku
2
800
Liquid Glass革新とSwiftUI/UIKit進化
fumiyasac0921
0
300
Connect 100+を支える技術
kanyamaguc
0
150
Featured
See All Featured
Unsuck your backbone
ammeep
671
58k
GraphQLとの向き合い方2022年版
quramy
49
14k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
KATA
mclloyd
30
14k
Scaling GitHub
holman
459
140k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Automating Front-end Workflow
addyosmani
1370
200k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
20
1.3k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
Typedesign – Prime Four
hannesfritz
42
2.7k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
Transcript
〜 Architecture を事前準備して臨んだ開発を振り返る 〜 Android Architecture を明文化して 新規開発に臨んだ話 Akihiko Sato
#78 iOS / Android 開発 Tips 共有会
自己紹介 佐藤 晶彦 株式会社ラクス 楽楽精算開発 モバイル開発 / Lead Engineer SaaS
(Backend, Frontend) / Mobile (iOS, Android) 主な業務は、設計 〜 受入、チームの課題改善など 最近のマイブームは、縄跳びトレーニング
今日伝えたいこと 開発開始前に Architecture を明文化して 良かったこと & 課題となったこと
背景 弊社では、 Native (Kotlin) 版と Cordova 版の 2 つの Android
アプリをリリースしています。 昨年 Native 版では Android 12 対応などを進めて来ましたが、 Cordova 版では FW のリリースと開発期間が合わないこともあり、 タイムリーな対応ができない状況でした。
背景 2 また、今後 Cordova 自体の開発が終了して EOL となった場合、 セキュリティリスクが生じる可能性も。。。
背景 3 他にも、市場に Cordova 開発者が少なくなっており、 採用面においてもなかなか厳しい状況でした・・・。 心機一転 Native 版に作り替えることになりました!
Android チームの現状 しかしながら、 Android チームは若手が中心で、 開発の苦戦は目に見えていたため、 事前に基本的方針として Architecture を定めることしました。
Architecture 選定にあたって 基本型として MVVM Architecture を採用することにしました。 まず Architecture を選定するにあたり ・
Android の公式 Architecture である ・モダンな Architecture を扱える技術力あるチームではない
Architecture 選定にあたって MVVM Architecture は 2017~8 年位から RxJava を主軸に 台頭した
Architecture ですが、 Jetpack Compose の進化と今後の展望を考えると、 Android の標準 Architecure として MVVM Architecture は 今後も Architecture として運用しやすいと考えました。
Architecture 選定にあたって 加えて Architecture 検討する上で関心の分離を重要な原則とし、 クラスの責務をできるだけシンプルに保つことで、 ライフサイクルに関連する多くの問題を回避し、 クラスごとのテストの容易性を向上させることにしました。
3 層レイヤー構造による構成 基本的なレイヤー構造として、 ・プレゼンテーションレイヤー ・ドメインレイヤー ・データレイヤー 3 層 MVVM Architecture
構成を採用
プレゼンテーション層( 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 ・ DI Module ・責務 ・命名規則 ・ルール(制約) ・実装例 ・テストで確認すること ・テスト実装例 明文化 ルールを明文化して、サンプルプロジェクトも用意
開発を進めて感じたこと ・チームの基本的技術力が向上 ・開発中に基本的なアーキテクチャの議論することがない 👉 開発に集中できる 👉 チームの生産性が高まった ・責務によりクラスを小さく分けたためテストが書きやすかった 👉 テスト品質の担保
課題に感じたこと ・ Package 構造 👉 技術駆動パッケージングよる参照関係 👉 レイヤー横断的な component をどう扱うか
・各レイヤーごとのによる依存性 👉 依存関係逆転原則を活用できていない 今後改善予定
まとめ Architecture を明文化すると 👉 チームの基本技術の向上 👉 チームの生産性の向上 👉 品質の向上 といった恩恵を受けることができるので、
皆様のチームでもトライしてみてはいかがでしょうか。
オンラインイベントや中途採用を積極的に行ってます! 最後に
ご清聴ありがとうございました