Vue.jsによるSPAの DDDについて考える(導⼊編) 2018-01-20 Gunma.web #30 堀 貴詞

⾃⼰紹介 • 名前: 堀 貴詞 • Twitter: @t_pori418 • JavaScript, PHP, Python … • Vue.js, Laravel … • 業務webアプリ開発

どのようなアプローチで ドメイン駆動設計を 実装で実現するかを考えます

経緯 1. 短い期間で機能継ぎ⾜しを繰り返されて 作られたシステム 2. 品質、保守性の低さ 3. システムを移⾏→DDDの考えを取り⼊れる • やっていること： SPA+APIで業務アプリ開発 vue.js + laravel を使⽤

今回考えるのは フロントエンドに絞ります

課題 画⾯主体の実装 • 画⾯(page)駆動開発になりがち • 複雑なロジックが書かれた共通コンポーネント • データ構造が画⾯依存(APIの設計にも問題あり) • テストができないコード・・・

フロントエンドのDDD • 部品となるコンポーネントは関⼼事で まとめて分ける • ただし最⼩コンポーネントは汎⽤的になる • データモデル,ビジネスロジックは関⼼事でま とめて分ける • ビジネスロジックやviewに渡すデータ整形処理を ドメインモデルと結びつけ整理する

データモデルとドメインモデル • Storeパターンの活⽤→vuexの導⼊ • 取得したデータはドメイン毎にstateで保持 • コンポーネント内の⼀時的なデータはモデルに 渡して保持

View Methods Data Actions Mutations State Backend API DevTool Computed Vuex Vue Components

View Methods Data Actions Mutations State Backend API DevTool Computed Vuex Vue Components model

安定したオブジェクトにする • TypeScriptの採⽤ • TypeScriptで型安全を⽬指す • 不変な値のためのオブジェクトの実装 • 基本的なデータはvuexのstateに保持している → mutationsで不正値が⼊らないかチェック • ⼀時的なデータはコンポーネントに持っている →不正値チェックは外部のクラス

vuex

失敗するTest

実際の処理例 action: model: method:

課題 • コンポーネント(view)に密結合するビジネスロ ジックがドメインモデルに切り出せない →改善できそうなところは多い • Vuexで状態管理しているデータはコミットすれ ばどこからでも容易に変更が可能である →vuexに保持しているデータを使⽤時にモデル に格納すべき？

まとめ • 画⾯主体、データ主体の実装にならないように • ドメインモデルに分け修正時の変更対象を狭く • 部分的なDDDの実装は有効