Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
ポイントサービス設計の異常な挑戦 または我々は如何にして心配するのを止めてドメイン駆動設計を愛...
Search
ニフティ株式会社
PRO
November 27, 2023
Video
Resources
Programming
0
440
ポイントサービス設計の異常な挑戦 または我々は如何にして心配するのを止めてドメイン駆動設計を愛するようになったか - NIFTY Tech Day 2023
ニフティ株式会社
PRO
November 27, 2023
Tweet
Share
Video
Resources
NIFTY Tech Day 2023
https://techday.nifty.co.jp/2023/
More Decks by ニフティ株式会社
See All by ニフティ株式会社
FourKeysを導入したが生産性向上には至らなかった理由
niftycorp
PRO
1
20
モニタリングダッシュボード に表示しておきたい情報 / NIFTY Tech Talk #21
niftycorp
PRO
1
57
PagerDutyを導入して変わったシステム運用とこれから / NIFTY Tech Talk #21
niftycorp
PRO
1
57
ゼロからボトムアップで始めるインナーソース ニフティのリアル事例 - InnerSource Gathering Tokyo 2024
niftycorp
PRO
2
130
FourKeysを導入したが生産性向上には至らなかった理由
niftycorp
PRO
5
5k
AWS Summit Japan 2024, AWS Game Day 振り返り - NIFTY Tech Talk #20
niftycorp
PRO
2
260
2つのスクラムチームの 調和的な協働・連携について - ニフティのスクラムトーク Vol. 3 / NIFTY Tech Talk #19
niftycorp
PRO
1
44
チーム力を高めるスクラム実践法:カンバン公開と課題攻略について - ニフティのスクラムトーク Vol. 2 - NIFTY Tech Talk #18
niftycorp
PRO
1
230
スクラムチームと認知負荷 - ニフティのスクラムトーク Vol2. / NIFTY Tech Talk #18
niftycorp
PRO
1
210
Other Decks in Programming
See All in Programming
Wallet API, Verifier APIで実現するIDカード on iPhoneの世界
shitamori1272
1
320
ドメイン駆動設計を実践するために必要なもの
bikisuke
3
290
Playwrightから始めるVisual Regression Testingのススメ by とっと
totto2727
2
1.8k
Mastering AsyncSequence - 使う・作る・他のデザインパターン(クロージャ、Delegate など)から移行する
treastrain
3
1.3k
初めてのiOS関連GitHub ActionsをMarketplaceに公開するまでの実録
konifar
3
200
大公開!iOS開発の悩みトップ5 〜iOSDC Japan 2024〜
ryunakayama
0
180
Swiftコードバトル必勝法
toshi0383
0
140
Appleの新しいプライバシー要件対応: ノーコードアプリ プラットフォームの実践事例
nao_randd
1
450
Uncharted packages (Laravel Live Denmark)
freekmurze
0
140
dotfiles について話したい #湘なんか
stefafafan
2
280
Rubyとクリエイティブコーディングの輪の広がり / The Growing Circle of Ruby and Creative Coding
chobishiba
1
220
ECMAScript、Web標準の型はどう管理されているか / How ECMAScript and Web standards types are maintained
petamoriken
3
370
Featured
See All Featured
Being A Developer After 40
akosma
82
580k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
157
15k
Build The Right Thing And Hit Your Dates
maggiecrowley
29
2.2k
The Straight Up "How To Draw Better" Workshop
denniskardys
230
130k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
27
8.9k
The World Runs on Bad Software
bkeepers
PRO
64
11k
From Idea to $5000 a Month in 5 Months
shpigford
378
46k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
246
1.3M
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
226
52k
Raft: Consensus for Rubyists
vanstee
135
6.5k
Making the Leap to Tech Lead
cromwellryan
128
8.8k
Transcript
Copyright ©NIFTY Corporation All Rights Reserved. ポイントサービス設計の異常な挑戦 または 我々は如何にして心配するのを止めてドメ イン駆動設計を愛するようになったか
会員システムグループ 第2開発チーム 関 歩武
自己紹介 • 名前 • 関 歩武 • 勤続年数 • 3年目
• 所属 • 会員システムグループ 第二開発チーム • ドメイン駆動設計経験 • ほとんどなし
初めに 4 • タイトルは「博士の異常な愛情 または私は如何にして心配 するのを止めて水爆を愛するようになったか」のパロディで す。思ったより内容に合ってないです(完全に私のミスです) • 今日の内容は設計初心者である私がどのようにポイントシス テムの刷新業務で設計を行ったか、どのような反省点があっ
たかを話します • 本資料に記述している内容は私見が入っています • 筆者は設計初心者のため間違った内容が多量に含まれている 可能性があります
Copyright ©NIFTY Corporation All Rights Reserved. ポイントシステムと ドメイン駆動設計 5
の紹介
ポイントサービスの歴史 1996年: iMiネット事業として事業を開始 2002年: ポイント事業開始 2005年: ニフティ株式会社子会社化 2011年: ライフメディアにブランドチェンジ 2018年:
ニフティ子会社としてニフティネクサス株式会社に再編 2020年: ニフティ株式会社のポイントサービスとして再編 2021年: ニフティポイントクラブにブランドチェンジ 25年以上続く老舗サービス 様々なシステムの統合や開発を繰り返して、現在のポイントシステムとなった
ポイントサービスの全体像 インフラ システムや各種サブシステム 一部バッチや一部サブシステム
過去の開発では(聞いた話) 9 システムA システムB システムC 開発 開発 開発
過去の開発では(聞いた話) 10 システムA システムB システムC 開発 開発 開発 システム間に共通のルールはなし 各々が各々で好きなように機能開発し
共通のルールはなし
ポイントサービスの問題点 12 • ポイント交換バッチ • ポイント付与生成 バッチ • etc 分析用システム
システム 運用者 合わせる 機能重複 システムの用途が 分かれていない From システム to 運用者
ポイントサービスの問題点 13 テスト システムAの 成果取り込み バッチ システムAの ステータス 更新バッチ システムBの
ポイント付与ファイル 作成バッチ システムCの ポイント付与バッチ 早朝 お昼 お昼明け 毎時
15 これらの問題を解決するためのルールが必要だった
Copyright ©NIFTY Corporation All Rights Reserved. ドメイン駆動設計に 白羽の矢が立った 17
2022年の12月ごろから刷新の作業が始まった • 一部クラウドの変更 • Railsバージョンの変更 • 一部機能の刷新 機能刷新では ドメイン駆動設計を取り入れよう
ドメイン駆動設計とは 現実世界の事柄をドメインとして切り出し、ドメインモデル化 してソフトウェアに落とし込む手法 学校モデル
例 20 ユーザドメイン ユーザドメインの ドメインモデル化 モデルのコード化 AYUMUというユーザ 年齢、性別、名前、生年月日、髪の色、唇 の色、話の癖…etc システムに必要なデータに
絞ってモデル化 モデルからルールに則って システムへの実装
ポイントサービスの問題点(再) 23 システム 運用者 合わせる From システム to 運用者
ドメイン駆動設計を使用することで 24 現実世界での運用変更を より反映しやすく エンジニア ビジネス より簡単に
ポイントサービスの問題点 25 テスト システムAの 成果取り込み バッチ システムAの ステータス 更新バッチ システムBの
ポイント付与ファイル 作成バッチ システムCの ポイント付与バッチ 早朝 お昼 お昼明け 毎時
ポイントサービスの問題点 26 • ポイント交換バッチ • ポイント付与生成 バッチ • etc 分析用システム
機能重複 システムの用途が 分かれていない
ドメイン駆動設計を使用することで 27 現実 システム より近く より書きやすく テストコード よりまとまりを持って
28 ポイントシステムが抱えている各種問題を解決できる可能性
30 ドメイン駆動設計を使って 刷新の設計をしていきましょう
Copyright ©NIFTY Corporation All Rights Reserved. 刷新での設計の軌跡 31
以下のように進めていきました? • コアドメインの決定 • 優先的に行うドメインの決定 • 優先的に作る機能の決定 • ユースケースとシステムフローの作成 •
ドメインロジックとメソッドなどの設計 • Rails実装時の設計
Copyright ©NIFTY Corporation All Rights Reserved. コアドメインの決定 33
コアドメインとは? コアドメインは事業的に他と差別化される最も重要なものであ り、最優先で取り組まれるドメインのことです コーヒーにこだわっているカフェ コアドメイン サブドメイン
ドメインエキスパートのような人に話を聞くのが良い コアドメインはドメインを知っている人(ドメインエキスパー ト)に話を聞くのが良い -> ポイントサービスはドメインエキスパートが存在しない状態
コアドメインの設計 36 機能からドメインとなるようにまとまりを作っていった 機能一覧の 作成 機能を まとめていく サブドメインと コアドメインを分ける 細かい!!
コアドメインの決定 37 最終的に以下のようにコアドメインを決定 • ポイントをお得に貯める • 広告 • ポイント利用 •
ポイント付与 • ユーザ種別
Copyright ©NIFTY Corporation All Rights Reserved. 優先的に行うドメインの決定 38
コアドメインが複数出たが、優先順位をつける必要がある 39 もっとも、運用上苦労しており、重要なものは何か?を考えた
2020年のニフティ統合とその後の開発 40 • 2020年: ニフティ統合 • 2021年: 高還元対応 ログイン可能に 接続会員に
高ポイント付与
2020年ポイント統合での問題 41 • ログインや入会の複雑化 • 会員種別の複雑化 • 様々な場所にロジックが分散、処理の肥大化 • お客様の混乱
• 運用コスト増加 今回はユーザ種別部分を 優先的に取り掛かることに決定
Copyright ©NIFTY Corporation All Rights Reserved. 優先的に作る機能の決定 42
会員管理の中のどの機能を優先的に作成するかを決める 43 仕様が決定しており、作りやすいものを設計した -> ポイント付け替え用ツール作成を選択 ポイント アカウントA アカウントB ポイント 別アカウントが持っているポイントを
別アカウントに移行する
Copyright ©NIFTY Corporation All Rights Reserved. ユースケースと システムフローの作成 44
ドメインを作成するためにユースケースなどを考えた 45
Copyright ©NIFTY Corporation All Rights Reserved. ドメインなどの詳細設計 46
例 47 ユーザドメイン ユーザドメインの ドメインモデル化 モデルのコード化 AYUMUというユーザ 年齢、性別、名前、生年月日、髪の色、唇 の色、話の癖…etc システムに必要なデータに
絞ってモデル化 モデルからルールに則って システムへの実装
ドメイン駆動設計のアーキテクチャ層 ドメイン駆動設計では以下のようなアーキテクチャの層で開 発することが多い プレゼンテーション層 アプリケーション層 ドメイン層 インフラストラクチャ層
アーキテクチャで何をするかを決めるために流れに沿ってそ れらをまとめた 49 集合 機能名(責務) プレゼンテーション 層 ユースケース層 ドメイン層 リポジトリ層
DB・UMPS 処理 アカウント付け替え 準備(確認画面前) 前アカウント情報 の取得 呼び出し アカウント付け替え 準備 アカウント情報 - @nifty ID - 登録者ID other_system_use r 削除フラグfalse @nifty IDを取得し、 その情報を other_system_use rテーブルから selectする 前アカウント履歴 集約の取得 呼び出し アカウント付け替え 準備 アカウント履歴集 約 - @nifty ID - 登録者ID other_system_use r 上で取得した情報 でアカウント履歴集 約を作成する 後アカウント情報 の取得 呼び出し アカウント付け替え 準備 アカウント情報 - @nifty ID - 登録者ID other_system_use r @nifty IDを取得し、 その情報を other_system_use rテーブルから selectする 後アカウント履歴 集約の取得 呼び出し アカウント付け替え 準備 アカウント履歴集 約 - @nifty ID - 登録者ID other_system_use r 上で取得した情報 でアカウント履歴集 約を作成する
流れからそれぞれの層のオブジェクトを設計 50 ドメイン層の一部
Copyright ©NIFTY Corporation All Rights Reserved. Railsのディレクトリ構成と どのように実装するかの決定 51
考え中 52
Copyright ©NIFTY Corporation All Rights Reserved. こうして一部のツールで設計が 終了し、ある程度作れる 状況になりました めでたしめでたし
Copyright ©NIFTY Corporation All Rights Reserved. な訳ない
Copyright ©NIFTY Corporation All Rights Reserved. これは後から考えた 理想的な流れ
実際の流れ 1. Railsでどのようにドメイン駆動設計を取り入れるか?を考える 2. コアドメインの決定 3. どのコアドメインについて刷新に取り掛かっていくか 4. 会員管理の中のドメインを細分化する 5.
ユースケースとデータモデリングの作成 6. データの種別を考える 7. オブジェクトの集約を考える 8. ドメインロジックを考える 9. 再度ユースケースとシステムフローを考える 10. どの機能を優先的に作るかを決める 11. 入会とログイン部分のドメイン設計などを行う 12. 優先的に作る機能の再検討 13. アカウント付け替えツールのドメイン設計などを行う 14. 処理の流れの作成 15. Railsに当てはめていく なぜか二度考える ユースケース ドメインを決めた後に ユースケースなどが出 てくる 優先的に開発する機能 の再検討 初っ端にRailsの話が 出てくる謎
Copyright ©NIFTY Corporation All Rights Reserved. なぜ紆余曲折を経たか 反省と失敗 58
FAULT1: 詳細に目を向けすぎていた 何をやるのか?が決まらないまま詳細を決めようとしたため、 設計がうまくまとまらなかった ドメイン駆動設計 初め 後
FAULT2:小さく機能を考えて設計すべきだった 最初の設計時に作成したドメイン
FAULT2:小さく機能を考えて設計すべきだった 全体像の機能を網羅的に考えるのは非常に難しい ユースケースごとにドメインを考えて、場合によってはそれらを統合する 形で進めたほうが良かった
FAULT4:仕様が決まっていないものを設計しようとした 新ログイン画面
FAULT4:仕様が決まっていないものを設計しようとした ボク ある程度、仕様が決まってるやろ 実際にフローなどを確認し、考えていった… ボク あれ?これって詰めてないな? などのことが多かった
その他のFAULT • 実装と設計は同時で進行させたほうが良い • 設計してても詳細が見えないので、小さい • 運用者や使用者の声は聞いたほうが良い • 設計後に色々とそうじゃないことが出てくる
教訓 • より現実世界に近い物事からシステムの流れで設計をする • 全体からではなく小さい機能から設計をしていく • 仕様が決まっているか改めて考えて設計に入る
突然コラム: 参考になった本の紹介 67
Copyright ©NIFTY Corporation All Rights Reserved. 今後の展望 68
今後の展望 • 会員管理部分をドメイン駆動設計で作り替える • ドメイン駆動設計のルール作り • ドメイン駆動設計の勉強会の開催 • 継続的な刷新を通してシステムを作り変えていく ポイントサービスのシステムを
変更や保守がしやすいシステムへ
ポイントチーム。採用やってます。 70 https://hrmos.co/pages/nifty/jobs/0000001
Copyright ©NIFTY Corporation All Rights Reserved. ご清聴ありがとうございました 71