フロントエンドでDDDやってみた

「#Webフロントエンド なんでもLT 会 #5」での発表内容です。
https://ncdc-dev.connpass.com/event/248156/

Transcript

1. フロントエンドで DDDやってみた 2022/06/17
2. 自己紹介 • 名前：ak2ie（あっきー） • システムエンジニア9年目 • 好きなもの：コーヒー、電車
3. DDD（ドメイン駆動設計）とは？ • システムの対象領域（ドメイン）に焦点を当てた設定手法 • ValueObject、Entity、ドメインサービスを使ってドメインの知識を表現 • リポジトリ、アプリケーションサービス、ファクトリを用いてシステムを構成
4. DDD関連書籍 本家 実践的 入門
5. 対象のプロジェクト • 自治体に納めた税金の使途を表示するサイト • 年収を入力すると、福祉や建築といった使途別に税額が表示される ※業務外のプロジェクトです
6. 構成 • Nuxt（ver.2）、TypeScript • フォルダ構成 ◦ root ▪ components ▪ page ▪ plugins：DDD関連のコード ▪ store
7. ユビキタス言語 • 論理名と物理名を用語集としてまとめた • ドメイン知識を持った方は1,2名、チームメンバーは5名程度だったので、 大きなものは作らなかった
8. ValueObject • ドメイン固有の概念を値として表す • 「金額」や「税率」を ValueObjectとして定義 • 作成時の数値チェックや金額計算のミスを防止 export class Price extends PrimitiveValueObject <number> { static create(value: number): Price { if (value < 0) { throw new Error('金額には0円以上を指定してください ') } return new Price(value) }
9. ValueObject • 加算：金額同士のみ public add(value: Price) { return Price.create(this.price + value.price) } • 乗算：金額×税率 public times(value: TaxRate) { return Price.create(this.price * value.rate) }
10. Entity • 属性が変わっても変化しないもの • 「個人」をEntityとして定義 export class Person { private salary: Price private homeType: HOME_TYPE }
11. ドメインサービス • ドメインに関する処理を行う • 年収から使途ごとの税額を計算する • 単体テストも書きやすい（Jestを使用）
12. ドメインサービス export class TaxService { /** * 一日当たりの税額算出 * @param param * @returns 税額（単位 :円） */ public calcTax(param: { person: Person government : Government cofogCode : CofogCode }): Price | null { const taxAmount = this.calcAmountTax ({ person: param.person, government: param.government , })
13. ドメインのテスト const person = new Person({ salary: Price.create(10000000 ), homeType: HOME_TYPE .SINGLE, }) const govFactory = new GovernmentFactory (wrapper.vm) const goverment = govFactory .Get() const service = new TaxService (wrapper.vm) expect( service.calcTax({ person, government: goverment , cofogCode: CofogCode .create({...}), }) ).toEqual(Price.create(((10000000 - 330000) * 0.06 * 2000) / 10000 / 365))
14. リポジトリ • StoreやAPIからのデータ取得はリポジトリを通して行うことで統一した export class HogeRepository { public GetStoreData(): Data | null { const storeData = this.app.store?.getters['storeData'] } } export class HogeHogeRepository { public async GetAPIData(): Promise<APIResponse> { const apiResponse = await this.app.$axios.$get<APIResponse>(uri) } }
15. リポジトリの利用 • リポジトリ名の候補が効く
16. リポジトリの定義 declare module '@nuxt/types' { interface NuxtAppOptions { readonly $repositories: <K extends keyof Repositories>(key: K) => ReturnType<Repositories[K]> } } declare module 'vue/types/vue' { interface Vue { readonly $repositories: <K extends keyof Repositories>(key: K) => ReturnType<Repositories[K]> } }
17. リポジトリの定義 export const repositories: Repositories = { cofog: CofogRepository, cofogData: CofogDataRepository, budget: BudgetRepository, }
18. アプリケーションサービス • システムとして構成させるための処理 • APIへのリクエストなど
19. ファクトリ • リポジトリはファクトリを通して取得、使用するようにした • ファクトリを使うようにしたが、中身は少なかったので使う意味があまりな かったかも知れない export const apiRepositoryFactory = { get: (key: keyof Repositories) => repositories[key] }
20. まとめ • コード全体の見通しがよくなった • テスト対象範囲が狭くなり、テストが書きやすかった • コード量が多くなってしまった