ポイントサービス設計の異常な挑戦 または我々は如何にして心配するのを止めてドメイン駆動設計を愛するようになったか - NIFTY Tech Day 2023

Transcript

1. Copyright ©NIFTY Corporation All Rights Reserved. ポイントサービス設計の異常な挑戦 または 我々は如何にして心配するのを止めてドメ イン駆動設計を愛するようになったか 会員システムグループ 第2開発チーム 関 歩武
2. 自己紹介 • 名前 • 関 歩武 • 勤続年数 • 3年目 • 所属 • 会員システムグループ 第二開発チーム • ドメイン駆動設計経験 • ほとんどなし
3. 初めに 4 • タイトルは「博士の異常な愛情 または私は如何にして心配 するのを止めて水爆を愛するようになったか」のパロディで す。思ったより内容に合ってないです(完全に私のミスです) • 今日の内容は設計初心者である私がどのようにポイントシス テムの刷新業務で設計を行ったか、どのような反省点があっ たかを話します • 本資料に記述している内容は私見が入っています • 筆者は設計初心者のため間違った内容が多量に含まれている 可能性があります
4. Copyright ©NIFTY Corporation All Rights Reserved. ポイントシステムと ドメイン駆動設計 5
5. の紹介
6. ポイントサービスの歴史 1996年: iMiネット事業として事業を開始 2002年: ポイント事業開始 2005年: ニフティ株式会社子会社化 2011年: ライフメディアにブランドチェンジ 2018年: ニフティ子会社としてニフティネクサス株式会社に再編 2020年: ニフティ株式会社のポイントサービスとして再編 2021年: ニフティポイントクラブにブランドチェンジ 25年以上続く老舗サービス 様々なシステムの統合や開発を繰り返して、現在のポイントシステムとなった
7. ポイントサービスの全体像 インフラ システムや各種サブシステム 一部バッチや一部サブシステム
8. 過去の開発では(聞いた話) 9 システムA システムB システムC 開発 開発 開発
9. 過去の開発では(聞いた話) 10 システムA システムB システムC 開発 開発 開発 システム間に共通のルールはなし 各々が各々で好きなように機能開発し 共通のルールはなし
10. ポイントサービスの問題点 12 • ポイント交換バッチ • ポイント付与生成 バッチ • etc 分析用システム システム 運用者 合わせる 機能重複 システムの用途が 分かれていない From システム to 運用者
11. ポイントサービスの問題点 13 テスト システムAの 成果取り込み バッチ システムAの ステータス 更新バッチ システムBの ポイント付与ファイル 作成バッチ システムCの ポイント付与バッチ 早朝 お昼 お昼明け 毎時
12. 15 これらの問題を解決するためのルールが必要だった
13. Copyright ©NIFTY Corporation All Rights Reserved. ドメイン駆動設計に 白羽の矢が立った 17
14. 2022年の12月ごろから刷新の作業が始まった • 一部クラウドの変更 • Railsバージョンの変更 • 一部機能の刷新 機能刷新では ドメイン駆動設計を取り入れよう
15. ドメイン駆動設計とは 現実世界の事柄をドメインとして切り出し、ドメインモデル化 してソフトウェアに落とし込む手法 学校モデル
16. 例 20 ユーザドメイン ユーザドメインの ドメインモデル化 モデルのコード化 AYUMUというユーザ 年齢、性別、名前、生年月日、髪の色、唇 の色、話の癖…etc システムに必要なデータに 絞ってモデル化 モデルからルールに則って システムへの実装
17. ポイントサービスの問題点(再) 23 システム 運用者 合わせる From システム to 運用者
18. ドメイン駆動設計を使用することで 24 現実世界での運用変更を より反映しやすく エンジニア ビジネス より簡単に
19. ポイントサービスの問題点 25 テスト システムAの 成果取り込み バッチ システムAの ステータス 更新バッチ システムBの ポイント付与ファイル 作成バッチ システムCの ポイント付与バッチ 早朝 お昼 お昼明け 毎時
20. ポイントサービスの問題点 26 • ポイント交換バッチ • ポイント付与生成 バッチ • etc 分析用システム 機能重複 システムの用途が 分かれていない
21. ドメイン駆動設計を使用することで 27 現実 システム より近く より書きやすく テストコード よりまとまりを持って
22. 28 ポイントシステムが抱えている各種問題を解決できる可能性
23. 30 ドメイン駆動設計を使って 刷新の設計をしていきましょう
24. Copyright ©NIFTY Corporation All Rights Reserved. 刷新での設計の軌跡 31
25. 以下のように進めていきました? • コアドメインの決定 • 優先的に行うドメインの決定 • 優先的に作る機能の決定 • ユースケースとシステムフローの作成 • ドメインロジックとメソッドなどの設計 • Rails実装時の設計
26. Copyright ©NIFTY Corporation All Rights Reserved. コアドメインの決定 33
27. コアドメインとは? コアドメインは事業的に他と差別化される最も重要なものであ り、最優先で取り組まれるドメインのことです コーヒーにこだわっているカフェ コアドメイン サブドメイン
28. ドメインエキスパートのような人に話を聞くのが良い コアドメインはドメインを知っている人(ドメインエキスパー ト)に話を聞くのが良い -> ポイントサービスはドメインエキスパートが存在しない状態
29. コアドメインの設計 36 機能からドメインとなるようにまとまりを作っていった 機能一覧の 作成 機能を まとめていく サブドメインと コアドメインを分ける 細かい!!
30. コアドメインの決定 37 最終的に以下のようにコアドメインを決定 • ポイントをお得に貯める • 広告 • ポイント利用 • ポイント付与 • ユーザ種別
31. Copyright ©NIFTY Corporation All Rights Reserved. 優先的に行うドメインの決定 38
32. コアドメインが複数出たが、優先順位をつける必要がある 39 もっとも、運用上苦労しており、重要なものは何か?を考えた
33. 2020年のニフティ統合とその後の開発 40 • 2020年: ニフティ統合 • 2021年: 高還元対応 ログイン可能に 接続会員に 高ポイント付与
34. 2020年ポイント統合での問題 41 • ログインや入会の複雑化 • 会員種別の複雑化 • 様々な場所にロジックが分散、処理の肥大化 • お客様の混乱 • 運用コスト増加 今回はユーザ種別部分を 優先的に取り掛かることに決定
35. Copyright ©NIFTY Corporation All Rights Reserved. 優先的に作る機能の決定 42
36. 会員管理の中のどの機能を優先的に作成するかを決める 43 仕様が決定しており、作りやすいものを設計した -> ポイント付け替え用ツール作成を選択 ポイント アカウントA アカウントB ポイント 別アカウントが持っているポイントを 別アカウントに移行する
37. Copyright ©NIFTY Corporation All Rights Reserved. ユースケースと システムフローの作成 44
38. ドメインを作成するためにユースケースなどを考えた 45
39. Copyright ©NIFTY Corporation All Rights Reserved. ドメインなどの詳細設計 46
40. 例 47 ユーザドメイン ユーザドメインの ドメインモデル化 モデルのコード化 AYUMUというユーザ 年齢、性別、名前、生年月日、髪の色、唇 の色、話の癖…etc システムに必要なデータに 絞ってモデル化 モデルからルールに則って システムへの実装
41. ドメイン駆動設計のアーキテクチャ層 ドメイン駆動設計では以下のようなアーキテクチャの層で開 発することが多い プレゼンテーション層 アプリケーション層 ドメイン層 インフラストラクチャ層
42. アーキテクチャで何をするかを決めるために流れに沿ってそ れらをまとめた 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 上で取得した情報 でアカウント履歴集 約を作成する
43. 流れからそれぞれの層のオブジェクトを設計 50 ドメイン層の一部
44. Copyright ©NIFTY Corporation All Rights Reserved. Railsのディレクトリ構成と どのように実装するかの決定 51
45. 考え中 52
46. Copyright ©NIFTY Corporation All Rights Reserved. こうして一部のツールで設計が 終了し、ある程度作れる 状況になりました めでたしめでたし
47. Copyright ©NIFTY Corporation All Rights Reserved. な訳ない
48. Copyright ©NIFTY Corporation All Rights Reserved. これは後から考えた 理想的な流れ
49. 実際の流れ 1. Railsでどのようにドメイン駆動設計を取り入れるか?を考える 2. コアドメインの決定 3. どのコアドメインについて刷新に取り掛かっていくか 4. 会員管理の中のドメインを細分化する 5. ユースケースとデータモデリングの作成 6. データの種別を考える 7. オブジェクトの集約を考える 8. ドメインロジックを考える 9. 再度ユースケースとシステムフローを考える 10. どの機能を優先的に作るかを決める 11. 入会とログイン部分のドメイン設計などを行う 12. 優先的に作る機能の再検討 13. アカウント付け替えツールのドメイン設計などを行う 14. 処理の流れの作成 15. Railsに当てはめていく なぜか二度考える ユースケース ドメインを決めた後に ユースケースなどが出 てくる 優先的に開発する機能 の再検討 初っ端にRailsの話が 出てくる謎
50. Copyright ©NIFTY Corporation All Rights Reserved. なぜ紆余曲折を経たか 反省と失敗 58
51. FAULT1: 詳細に目を向けすぎていた 何をやるのか?が決まらないまま詳細を決めようとしたため、 設計がうまくまとまらなかった ドメイン駆動設計 初め 後
52. FAULT2:小さく機能を考えて設計すべきだった 最初の設計時に作成したドメイン
53. FAULT2:小さく機能を考えて設計すべきだった 全体像の機能を網羅的に考えるのは非常に難しい ユースケースごとにドメインを考えて、場合によってはそれらを統合する 形で進めたほうが良かった
54. FAULT4:仕様が決まっていないものを設計しようとした 新ログイン画面
55. FAULT4:仕様が決まっていないものを設計しようとした ボク ある程度、仕様が決まってるやろ 実際にフローなどを確認し、考えていった… ボク あれ?これって詰めてないな? などのことが多かった
56. その他のFAULT • 実装と設計は同時で進行させたほうが良い • 設計してても詳細が見えないので、小さい • 運用者や使用者の声は聞いたほうが良い • 設計後に色々とそうじゃないことが出てくる
57. 教訓 • より現実世界に近い物事からシステムの流れで設計をする • 全体からではなく小さい機能から設計をしていく • 仕様が決まっているか改めて考えて設計に入る
58. 突然コラム: 参考になった本の紹介 67
59. Copyright ©NIFTY Corporation All Rights Reserved. 今後の展望 68
60. 今後の展望 • 会員管理部分をドメイン駆動設計で作り替える • ドメイン駆動設計のルール作り • ドメイン駆動設計の勉強会の開催 • 継続的な刷新を通してシステムを作り変えていく ポイントサービスのシステムを 変更や保守がしやすいシステムへ
61. ポイントチーム。採用やってます。 70 https://hrmos.co/pages/nifty/jobs/0000001
62. Copyright ©NIFTY Corporation All Rights Reserved. ご清聴ありがとうございました 71