アプリのリニューアル時にDomainModelを削除した話(設計カンファレンス extends OOC 2024.3.29)

アプリのリニューアル時に DomainModelを削除した話土門@rd05011 設計カンファレンス extends OOC 2024.3.29

自己紹介 • 土門良輔(@rd05011) • iOS/Flutter Engineer • App Engineer @
WHITEPLUS, inc. ◦ 2023.4.1入社 ◦ 宅配クリーニング「リネット」のアプリを開発しています 2

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 よかったらダウンロードしてみてください

アプリのリニューアル時にDomainModelを削除した話(設計カンファレンス extends...

アプリのリニューアル時にDomainModelを削除した話(設計カンファレンス extends OOC 2024.3.29)

domonr

More Decks by domonr

Other Decks in Technology

Featured

Transcript