2023.9.14 asken withミライトデザインのDDDのはじめ方 DDD x RDRA x ICONIX にて
株式会社ミライトデザイン 林宏勝
ドメインを中心にしたプロダクト開発asken withミライトデザインのDDDのはじめ方 DDD x RDRA x ICONIX2023.09.14 @林 宏勝(株式会社ミライトデザイン)資料 https://speakerdeck.com/hirodragon112/domain-driven-product
View Slide
ドメインを中心にしたプロダクト開発 2林 宏勝(X : hiro@miraito)株式会社ミライトデザイン CEOObject Oriented Conference2020主催ドメイン駆動設計入門レビュアーOOPやDDD中心に設計などに興味があります自己紹介
ドメインを中心にしたプロダクト開発 3「確かな設計によるよりよいシステムを」主に上流工程・コンサルから開発・運用まで幅広くプロダクト開発のお手伝いをしています会社紹介株式会社ミライトデザイン
ドメインを中心にしたプロダクト開発 4勉強会「ペチオブ」開催https://phper-oop.connpass.com/設計・アジャイル・要件定義・その他諸々プロダクト開発に関する色んな事を一緒に学ぼうという勉強会月一第一木曜日に開催中会社紹介
ドメインを中心にしたプロダクト開発 5Youtube :Mirait Channelhttps://www.youtube.com/@miraitoエンジニアリングに関する動画から関係ない動画まで不定期更新してますので、チャンネル登録よろしくお願いします!会社紹介
ドメインを中心にしたプロダクト開発 6ドメインを中心にしたプロダクト開発とは??
ドメインを中心にしたプロダクト開発 7その前に一般的に理想(理論)と現実のギャップが必ずある事を理解する• 全てを作り直す事はできないケースがある• データ構造にいきなり手を入れられないケースがある• 効果測定をしたくても既存システムにその仕組みがない(入れられない)• 等々理論の話しではなく実務の話しなのでその辺を気にしながら話します
ドメインを中心にしたプロダクト開発 8リニューアルの成功とは?既存課題が解決できる事潜在課題に対処できる事解決?対処?
ドメインを中心にしたプロダクト開発 9理想定量的に成功のGoalを決めたい現実既存の問題等を数値化する仕組みがない(数値化するのが困難)デプロイが楽になった修正や機能追加が容易になったソースコードが理解しやすくなった←定性的判断をひとまずPoCでしてもらう
ドメインを中心にしたプロダクト開発 10進める上で意識していること1. 教条主義にならない2. QCDS、特にSを明確にする3. 「何を」「なぜ」作るかを明確にする
ドメインを中心にしたプロダクト開発 11ドメインを中心にしたプロダクト ≠教科書通りのパターンを使うこと(エリックエバンスの)ドメイン駆動設計本通りのできているかどうかを指針としない。教条主義にならない
ドメインを中心にしたプロダクト開発 12ドメインを知りそれをシステムに投影できるかただ動くものではなく、ドメインを表現したシステム構造にできるか現実解が常に問われる
ドメインを中心にしたプロダクト開発 13全てを一気に作り直す事は現実的ではないが、現実的にどの単位でわけられるかも案外複雑Cost, Quality, は事業上必ず制約が発生するのでその上で適切なScope, Delivery を計画するQCDS、特にSを明確にする
ドメインを中心にしたプロダクト開発 14世のプロダクトの大半は、何を作れば良いかわからないまま何かを作っているプロダクト開発の恐怖の都市伝説「何を」「なぜ」作るかを明確にする既存システムをただトレースすると、既に不要な機能などもリニューアル対象になってしまう。改めてフローを整理し、どのユースケース、どの業務フローと結びついている機能かを明確にしていく
ドメインを中心にしたプロダクト開発 15知る 作る解決したい課題を知るドメインを知る(技術的)制約をを知る課題を解消したプロダクトドメインを表現したプロダクト制約を踏まえた現実解を探す進め方
ドメインを中心にしたプロダクト開発 16具体的に行った事1. 業務と関連するユースケースの洗い出し2. PoC期間に実装検証する対象のユースケース選定3. 概念モデル作成4. アーキテクチャ検討5. ユースケースから詳細設計までの流れの確認6. Kotlinにて対象ユースケースを実装してみる7. 上記を2~3サイクル回して、今後の開発フローとしていけるか確認
ドメインを中心にしたプロダクト開発 171. 業務と関連するユースケースの洗い出し2. PoC期間に実装検証する対象のユースケース選定Poc時に作成途中のRDRAシートRDRAで整理する主な目的• コンテキストの理解• 業務フロー整理• 状態、バリエーションの整理• ユースケース洗い出し• 各機能の「なぜ」を理解する
ドメインを中心にしたプロダクト開発 181. 業務と関連するユースケースの洗い出し2. PoC期間に実装検証する対象のユースケース選定RDRAで整理するPoc時に作成途中のRDRAダイアグラム
ドメインを中心にしたプロダクト開発 193.概念モデル作成Poc時に作成途中の概念モデルRDRA分析と並行して概念モデルを作成する主な目的• 概念整理• 用語の統一(ユビキタス言語)• スコープの確認
ドメインを中心にしたプロダクト開発 204. アーキテクチャ検討5.ユースケースから詳細設計までの流れの確認ICONIXプロセスを使用してユースケースを詳細に落としていく主な目的• 分析したユースケースを実装に近づける• 自然言語とオブジェクトのマッピング• ユースケースの規模の確認詳細はこちらDDD時代に考えたいICONIXプロセスhttps://speakerdeck.com/hirodragon112/iconix-in-ddd
ドメインを中心にしたプロダクト開発 216. Kotlinにて対象ユースケースを実装してみる選定言語にて実際の実装を行う主な目的• 選定技術の実用性の確認• 開発フローと速度の確認• チームに浸透しそうかの確認
ドメインを中心にしたプロダクト開発 22今後見えている課題1. データモデルの変更が行えない為、既存のデータモデルによる制約2. スパークタイム(昼食時)の非機能性能を確認3. PoC以降のチームビルド
ドメインを中心にしたプロダクト開発 23@hirodragon