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

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

No content

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