月: 2023年11月

個人開発のユーザー情報更新の処理を見ていて、もっと良くできるのではないかと思い、Clean ArchitectureとDDDをベースに理想状態を考えてみました。 現状のユーザー情報更新の流れ 現状のユーザー情報更新までの流れはこんな感じになっています。 まずユーザー情報のアイコン画像をStorageに保存して、そのパスとユーザー情報をFirestoreに更新します。その後、更新したユーザー情報をもとに一部の情報ブラウザのLocalStorageにするような流れになっています。 データの流れは基本的に画面がから受け取った値を横流しにしている感じになっており、アプリケーションとしての役割や領域が曖昧になってしまっています。また、アーキテクチャとしても簡易的なClean Architectureになっており、責務がしっかりと分けきれていない感じがしました。 そこで、この辺りの記事をあらためて読み返して、アプリケーションとしてのユースケースやコアドメインを洗い出しました。 https://mintaku-blog.net/ddd-api/ ユーザー情報更新のデータの流れや構成をこうしたい ということで、自分の中で色々整理して、理想のアーキテクチャやデータフロー（データの型は簡易的にしています）を考えてみました。 まずは、ドメインやエンティティとして領域ごとに型を用意しました。アプリケーションのコアとなる部分ではドメインとして扱い、サードパーティーなどを操作するDriver層ではエンティティとして扱うようにしました。 アプリケーションと外部の境界のGateway/Presenterにてデータの変換を行うようにします。また、Contoller層を用意し、Usecaseにドメインの型で渡すようにします。 まだまだかもですが、これでだいぶ責務の切り分けはできてきたかと思います。きっちりやろうとするとコード量が増えますが、コアなユースケースなので安全かつ複雑性を排除して、keep cleanの精神でリファクタリングしていきたいです。 まとめ 最近あんまりガッツリ開発に携わってないと、新鮮な目で設計とかリアーキ考えることができ、良い機会になりました。 あと考えていくうちに疑問点とか色々出てくるので、色んな人に聞いたり、議論しながらもっとブラッシュアップしてきたいと思いました。 他にもリファクタリングしたいところは多々あるので、コツコツやっていきたいと思います。

ユーザー情報更新のデータフローの理想状態を考える