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
アプリのリニューアル時にDomainModelを削除した話(設計カンファレンス extends...
Search
domonr
March 29, 2024
Technology
0
680
アプリのリニューアル時にDomainModelを削除した話(設計カンファレンス extends OOC 2024.3.29)
domonr
March 29, 2024
Tweet
Share
More Decks by domonr
See All by domonr
(iOS13の)UIBarButtonItem 位置調整あるある
domonr
0
1.1k
あるあるLT~文字列共通化~
domonr
0
600
あるあるLT_domonr_2019-03-19.pdf
domonr
0
1.5k
脱ぼっちレビュー_domonr
domonr
0
390
Other Decks in Technology
See All in Technology
Snowflake Intelligenceにはこうやって立ち向かう!クラシルが考えるAI Readyなデータ基盤と活用のためのDataOps
gappy50
0
280
下手な強制、ダメ!絶対! 「ガードレール」を「檻」にさせない"ガバナンス"の取り方とは?
tsukaman
2
460
20250910_障害注入から効率的復旧へ_カオスエンジニアリング_生成AIで考えるAWS障害対応.pdf
sh_fk2
3
280
Claude Code でアプリ開発をオートパイロットにするためのTips集 Zennの場合 / Claude Code Tips in Zenn
wadayusuke
5
1.4k
スクラムガイドに載っていないスクラムのはじめかた - チームでスクラムをはじめるときに知っておきたい勘所を集めてみました! - / How to start Scrum that is not written in the Scrum Guide 2nd
takaking22
1
170
テストを軸にした生き残り術
kworkdev
PRO
0
220
これでもう迷わない!Jetpack Composeの書き方実践ガイド
zozotech
PRO
0
1.1k
人工衛星のファームウェアをRustで書く理由
koba789
15
8.3k
まずはマネコンでちゃちゃっと作ってから、それをCDKにしてみよか。
yamada_r
2
120
「何となくテストする」を卒業するためにプロダクトが動く仕組みを理解しよう
kawabeaver
0
430
エンジニアリングマネージャーの成長の道筋とキャリア / Developers Summit 2025 KANSAI
daiksy
3
1.1k
職種の壁を溶かして開発サイクルを高速に回す~情報透明性と職種越境から考えるAIフレンドリーな職種間連携~
daitasu
0
170
Featured
See All Featured
Building Applications with DynamoDB
mza
96
6.6k
Keith and Marios Guide to Fast Websites
keithpitt
411
22k
Why Our Code Smells
bkeepers
PRO
339
57k
Testing 201, or: Great Expectations
jmmastey
45
7.7k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
18
1.1k
Designing for Performance
lara
610
69k
[RailsConf 2023] Rails as a piece of cake
palkan
57
5.8k
A Modern Web Designer's Workflow
chriscoyier
696
190k
YesSQL, Process and Tooling at Scale
rocio
173
14k
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.5k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
Transcript
アプリのリニューアル時に DomainModelを削除した話 土門@rd05011 設計カンファレンス extends OOC 2024.3.29
自己紹介 • 土門良輔(@rd05011) • iOS/Flutter Engineer • App Engineer @
WHITEPLUS, inc. ◦ 2023.4.1入社 ◦ 宅配クリーニング「リネット」のア プリを開発しています 2
None
4 アジェンダ アプリリニューアルに伴うリアーキテクチャのポイント リアーキテクチャ方針 01 02 アプリケーション層とドメイン層を削除 アプリケーション層を一部画面に復活させる 03 04
まとめ 05
5 01 アプリリニューアルに伴う リアーキテクチャのポイント
6 01 アプリリニューアルに伴うリアーキテクチャのポイント • アプリの役割が変化しそれに伴い求められる責務も変わってきた • 元々、多くの機能がネイティブ実装されていたため、アプリ側で 様々なロジックの実装を行なってた • 現在は、アプリ側にはロジックはあまり無く、サーバーから受け
取ったデータを表示することが主な責務になっている • よりシンプルな設計にすることで複雑性を下げることができ、開発 効率の向上が見込めると考えた
7 02 リアーキテクチャ方針
8 02 リアーキテクチャ方針 • 元々は、プレゼンテーション層、アプリケーション層、ドメイン層、インフラ 層の4つの層で構成されていた • しかし、現在のアプリではロジックはほぼ無くなり、主にデータの詰め替えの みを行っていた •
アプリケーション層とドメイン層を削除し、シンプルな設計に移行することに
9 03 アプリケーション層と ドメイン層を削除
10 03 アプリケーション層とドメイン層を削除 • アプリ側にロジックがほぼ無いため、必要なものはデータを取得す る層と表示する層だけなので、アプリケーション層とドメイン層を 削除 • 設計がシンプルになり、画面ごとのファイル数が減少し、不要な ファイルの作成時間もなくなり開発効率がアップ
11 しかし、問題発生
12 03 アプリケーション層とドメイン層を削除 • アプリ側にロジックがほぼ無いが、一部機能にはロジックがある • その画面でプレゼンテーション層が肥大化 • 全てのロジックがプレゼンテーション層に記載されるためコードの 複雑性も上昇
13 04 アプリケーション層を 一部画面に復活させる
14 04 アプリケーション層を一部画面に復活させる • プレゼンテーション層にView以外のロジックが入り込んでしまい、 複数のロジックが集中することで複雑性が上がってしまった • 一部だけUseCaseを復活させることで一部画面で発生した、アプリ ケーションロジックを分離し責務を分けることで、肥大化を避けた
15 05 まとめ
16 05 まとめ • ドメインロジックが無い場合はDomainModelは不要 ◦ アプリの場合は主な関心事がプレゼンテーション層のため、プレゼン テーション層以外はざっくりModelと表現されることが多い • 画面ごとに設計を変えることで過不足ない実装にすることができる
◦ アプリケーションロジックが必要な場合だけUseCaseを作成 ◦ ドメインロジックが必要な場合だけDomainModelを画面単位で導入 • アーキテクチャの軽量化を行うことで設計の複雑性を下げることができる ◦ 軽量化しすぎるとコードの複雑性が上がってしまうので注意
17 よかったらダウンロードしてみてください