Vuex + DDD のアーキテクチャを考える - Techtouch Developers Blog
フロントエンドエンジニアの国定です。 この記事では、TypeScript + Vue.js で開発しているフロントエンドに今年からドメイン駆動設計（DDD）を取り入れ始め、ひとまず設計が落ち着いてきたのでその経緯とアーキテクチャについて解説します。 課題 アーキテクチャ Domain Service Store（Vuex） UI（Vue.js） 軽量DDDに陥らないために まとめ 課題 Vuex（Store）の責務は、エラー判定などのドメインロジック・データの永続化・API の呼び出しなど、State 管理のほかにも多岐にわたっています。UI の改善や機能追加など変化の多いフロントエンドでは開発が進むにつれ Vue + Vuex のあちこちに同じ処理が散在してしまいます。 テックタッチでもメンテナンスを繰り返す度にコードの複雑さが増し、機能追加や修正に時間がかかるようになってきました。去年
ドメイン駆動Vuexで複雑さに立ち向かう
スタディスト開発部、フロントエンド担当の小宮山です。走ることが楽しくなりすぎてフルマラソン完走が当面の目標です。 今回は私達が進めているUIリニューアルプロジェクトにおける、フロントエンド設計の心臓部についてご紹介したいと思います。盛り上がりつつあるものの、まだまだ実践的な情報が少ないVue界隈に少しでも貢献できましたら幸いです。 画面駆動Vuexの頃プロジェクト始動当時は私含め大規模プロダクトにVuex（さらにその他Flux状態管理も）を導入して開発を進める経験も知見もほぼない状況でした。 そして開発していく画面デザインの大枠は出揃っている状態だったので、計画も実装も画面単位で区切って進みだしていきます。 こうした状況でVuexのstoreはどのような方針で実装されていくか。正確に表現するなら、特に方針なく実装していくとどうなるか。画面ファーストで、画面から使いやすく、画面ごとに専用なs
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
