Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

ニフティ株式会社

November 27, 2023
Tweet

More Decks by ニフティ株式会社

Other Decks in Programming

Transcript

  1. Copyright ©NIFTY Corporation All Rights Reserved.
    ポイントサービス設計の異常な挑戦 または
    我々は如何にして心配するのを止めてドメ
    イン駆動設計を愛するようになったか
    会員システムグループ 第2開発チーム
    関 歩武

    View full-size slide

  2. 自己紹介
    • 名前
    • 関 歩武
    • 勤続年数
    • 3年目
    • 所属
    • 会員システムグループ 第二開発チーム
    • ドメイン駆動設計経験
    • ほとんどなし

    View full-size slide

  3. 初めに
    4
    • タイトルは「博士の異常な愛情 または私は如何にして心配
    するのを止めて水爆を愛するようになったか」のパロディで
    す。思ったより内容に合ってないです(完全に私のミスです)
    • 今日の内容は設計初心者である私がどのようにポイントシス
    テムの刷新業務で設計を行ったか、どのような反省点があっ
    たかを話します
    • 本資料に記述している内容は私見が入っています
    • 筆者は設計初心者のため間違った内容が多量に含まれている
    可能性があります

    View full-size slide

  4. Copyright ©NIFTY Corporation All Rights Reserved.
    ポイントシステムと
    ドメイン駆動設計
    5

    View full-size slide

  5. ポイントサービスの歴史
    1996年: iMiネット事業として事業を開始
    2002年: ポイント事業開始
    2005年: ニフティ株式会社子会社化
    2011年: ライフメディアにブランドチェンジ
    2018年: ニフティ子会社としてニフティネクサス株式会社に再編
    2020年: ニフティ株式会社のポイントサービスとして再編
    2021年: ニフティポイントクラブにブランドチェンジ
    25年以上続く老舗サービス
    様々なシステムの統合や開発を繰り返して、現在のポイントシステムとなった

    View full-size slide

  6. ポイントサービスの全体像
    インフラ
    システムや各種サブシステム
    一部バッチや一部サブシステム

    View full-size slide

  7. 過去の開発では(聞いた話)
    9
    システムA
    システムB
    システムC
    開発
    開発
    開発

    View full-size slide

  8. 過去の開発では(聞いた話)
    10
    システムA
    システムB
    システムC
    開発
    開発
    開発
    システム間に共通のルールはなし
    各々が各々で好きなように機能開発し
    共通のルールはなし

    View full-size slide

  9. ポイントサービスの問題点
    12
    • ポイント交換バッチ
    • ポイント付与生成
    バッチ
    • etc
    分析用システム
    システム
    運用者
    合わせる
    機能重複
    システムの用途が
    分かれていない
    From システム to 運用者

    View full-size slide

  10. ポイントサービスの問題点
    13
    テスト
    システムAの
    成果取り込み
    バッチ
    システムAの
    ステータス
    更新バッチ
    システムBの
    ポイント付与ファイル
    作成バッチ
    システムCの
    ポイント付与バッチ
    早朝
    お昼
    お昼明け
    毎時

    View full-size slide

  11. 15
    これらの問題を解決するためのルールが必要だった

    View full-size slide

  12. Copyright ©NIFTY Corporation All Rights Reserved.
    ドメイン駆動設計に
    白羽の矢が立った
    17

    View full-size slide

  13. 2022年の12月ごろから刷新の作業が始まった
    • 一部クラウドの変更
    • Railsバージョンの変更
    • 一部機能の刷新
    機能刷新では
    ドメイン駆動設計を取り入れよう

    View full-size slide

  14. ドメイン駆動設計とは
    現実世界の事柄をドメインとして切り出し、ドメインモデル化
    してソフトウェアに落とし込む手法
    学校モデル

    View full-size slide


  15. 20
    ユーザドメイン
    ユーザドメインの
    ドメインモデル化
    モデルのコード化
    AYUMUというユーザ
    年齢、性別、名前、生年月日、髪の色、唇
    の色、話の癖…etc
    システムに必要なデータに
    絞ってモデル化
    モデルからルールに則って
    システムへの実装

    View full-size slide

  16. ポイントサービスの問題点(再)
    23
    システム 運用者
    合わせる
    From システム to 運用者

    View full-size slide

  17. ドメイン駆動設計を使用することで
    24
    現実世界での運用変更を
    より反映しやすく
    エンジニア
    ビジネス
    より簡単に

    View full-size slide

  18. ポイントサービスの問題点
    25
    テスト
    システムAの
    成果取り込み
    バッチ
    システムAの
    ステータス
    更新バッチ
    システムBの
    ポイント付与ファイル
    作成バッチ
    システムCの
    ポイント付与バッチ
    早朝
    お昼
    お昼明け
    毎時

    View full-size slide

  19. ポイントサービスの問題点
    26
    • ポイント交換バッチ
    • ポイント付与生成
    バッチ
    • etc
    分析用システム
    機能重複
    システムの用途が
    分かれていない

    View full-size slide

  20. ドメイン駆動設計を使用することで
    27
    現実
    システム
    より近く より書きやすく
    テストコード
    よりまとまりを持って

    View full-size slide

  21. 28
    ポイントシステムが抱えている各種問題を解決できる可能性

    View full-size slide

  22. 30
    ドメイン駆動設計を使って
    刷新の設計をしていきましょう

    View full-size slide

  23. Copyright ©NIFTY Corporation All Rights Reserved.
    刷新での設計の軌跡
    31

    View full-size slide

  24. 以下のように進めていきました?
    • コアドメインの決定
    • 優先的に行うドメインの決定
    • 優先的に作る機能の決定
    • ユースケースとシステムフローの作成
    • ドメインロジックとメソッドなどの設計
    • Rails実装時の設計

    View full-size slide

  25. Copyright ©NIFTY Corporation All Rights Reserved.
    コアドメインの決定
    33

    View full-size slide

  26. コアドメインとは?
    コアドメインは事業的に他と差別化される最も重要なものであ
    り、最優先で取り組まれるドメインのことです
    コーヒーにこだわっているカフェ
    コアドメイン
    サブドメイン

    View full-size slide

  27. ドメインエキスパートのような人に話を聞くのが良い
    コアドメインはドメインを知っている人(ドメインエキスパー
    ト)に話を聞くのが良い
    -> ポイントサービスはドメインエキスパートが存在しない状態

    View full-size slide

  28. コアドメインの設計
    36
    機能からドメインとなるようにまとまりを作っていった
    機能一覧の
    作成
    機能を
    まとめていく
    サブドメインと
    コアドメインを分ける
    細かい!!

    View full-size slide

  29. コアドメインの決定
    37
    最終的に以下のようにコアドメインを決定
    • ポイントをお得に貯める
    • 広告
    • ポイント利用
    • ポイント付与
    • ユーザ種別

    View full-size slide

  30. Copyright ©NIFTY Corporation All Rights Reserved.
    優先的に行うドメインの決定
    38

    View full-size slide

  31. コアドメインが複数出たが、優先順位をつける必要がある
    39
    もっとも、運用上苦労しており、重要なものは何か?を考えた

    View full-size slide

  32. 2020年のニフティ統合とその後の開発
    40
    • 2020年: ニフティ統合
    • 2021年: 高還元対応
    ログイン可能に
    接続会員に
    高ポイント付与

    View full-size slide

  33. 2020年ポイント統合での問題
    41
    • ログインや入会の複雑化
    • 会員種別の複雑化
    • 様々な場所にロジックが分散、処理の肥大化
    • お客様の混乱
    • 運用コスト増加
    今回はユーザ種別部分を
    優先的に取り掛かることに決定

    View full-size slide

  34. Copyright ©NIFTY Corporation All Rights Reserved.
    優先的に作る機能の決定
    42

    View full-size slide

  35. 会員管理の中のどの機能を優先的に作成するかを決める
    43
    仕様が決定しており、作りやすいものを設計した
    -> ポイント付け替え用ツール作成を選択
    ポイント
    アカウントA
    アカウントB
    ポイント
    別アカウントが持っているポイントを
    別アカウントに移行する

    View full-size slide

  36. Copyright ©NIFTY Corporation All Rights Reserved.
    ユースケースと
    システムフローの作成
    44

    View full-size slide

  37. ドメインを作成するためにユースケースなどを考えた
    45

    View full-size slide

  38. Copyright ©NIFTY Corporation All Rights Reserved.
    ドメインなどの詳細設計
    46

    View full-size slide


  39. 47
    ユーザドメイン
    ユーザドメインの
    ドメインモデル化
    モデルのコード化
    AYUMUというユーザ
    年齢、性別、名前、生年月日、髪の色、唇
    の色、話の癖…etc
    システムに必要なデータに
    絞ってモデル化
    モデルからルールに則って
    システムへの実装

    View full-size slide

  40. ドメイン駆動設計のアーキテクチャ層
    ドメイン駆動設計では以下のようなアーキテクチャの層で開
    発することが多い
    プレゼンテーション層
    アプリケーション層
    ドメイン層
    インフラストラクチャ層

    View full-size slide

  41. アーキテクチャで何をするかを決めるために流れに沿ってそ
    れらをまとめた
    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
    上で取得した情報
    でアカウント履歴集
    約を作成する

    View full-size slide

  42. 流れからそれぞれの層のオブジェクトを設計
    50
    ドメイン層の一部

    View full-size slide

  43. Copyright ©NIFTY Corporation All Rights Reserved.
    Railsのディレクトリ構成と
    どのように実装するかの決定
    51

    View full-size slide

  44. Copyright ©NIFTY Corporation All Rights Reserved.
    こうして一部のツールで設計が
    終了し、ある程度作れる
    状況になりました
    めでたしめでたし

    View full-size slide

  45. Copyright ©NIFTY Corporation All Rights Reserved.
    な訳ない

    View full-size slide

  46. Copyright ©NIFTY Corporation All Rights Reserved.
    これは後から考えた
    理想的な流れ

    View full-size slide

  47. 実際の流れ
    1. Railsでどのようにドメイン駆動設計を取り入れるか?を考える
    2. コアドメインの決定
    3. どのコアドメインについて刷新に取り掛かっていくか
    4. 会員管理の中のドメインを細分化する
    5. ユースケースとデータモデリングの作成
    6. データの種別を考える
    7. オブジェクトの集約を考える
    8. ドメインロジックを考える
    9. 再度ユースケースとシステムフローを考える
    10. どの機能を優先的に作るかを決める
    11. 入会とログイン部分のドメイン設計などを行う
    12. 優先的に作る機能の再検討
    13. アカウント付け替えツールのドメイン設計などを行う
    14. 処理の流れの作成
    15. Railsに当てはめていく
    なぜか二度考える
    ユースケース
    ドメインを決めた後に
    ユースケースなどが出
    てくる
    優先的に開発する機能
    の再検討
    初っ端にRailsの話が
    出てくる謎

    View full-size slide

  48. Copyright ©NIFTY Corporation All Rights Reserved.
    なぜ紆余曲折を経たか
    反省と失敗
    58

    View full-size slide

  49. FAULT1: 詳細に目を向けすぎていた
    何をやるのか?が決まらないまま詳細を決めようとしたため、
    設計がうまくまとまらなかった
    ドメイン駆動設計
    初め 後

    View full-size slide

  50. FAULT2:小さく機能を考えて設計すべきだった
    最初の設計時に作成したドメイン

    View full-size slide

  51. FAULT2:小さく機能を考えて設計すべきだった
    全体像の機能を網羅的に考えるのは非常に難しい
    ユースケースごとにドメインを考えて、場合によってはそれらを統合する
    形で進めたほうが良かった

    View full-size slide

  52. FAULT4:仕様が決まっていないものを設計しようとした
    新ログイン画面

    View full-size slide

  53. FAULT4:仕様が決まっていないものを設計しようとした
    ボク
    ある程度、仕様が決まってるやろ
    実際にフローなどを確認し、考えていった…
    ボク
    あれ?これって詰めてないな?
    などのことが多かった

    View full-size slide

  54. その他のFAULT
    • 実装と設計は同時で進行させたほうが良い
    • 設計してても詳細が見えないので、小さい
    • 運用者や使用者の声は聞いたほうが良い
    • 設計後に色々とそうじゃないことが出てくる

    View full-size slide

  55. 教訓
    • より現実世界に近い物事からシステムの流れで設計をする
    • 全体からではなく小さい機能から設計をしていく
    • 仕様が決まっているか改めて考えて設計に入る

    View full-size slide

  56. 突然コラム: 参考になった本の紹介
    67

    View full-size slide

  57. Copyright ©NIFTY Corporation All Rights Reserved.
    今後の展望
    68

    View full-size slide

  58. 今後の展望
    • 会員管理部分をドメイン駆動設計で作り替える
    • ドメイン駆動設計のルール作り
    • ドメイン駆動設計の勉強会の開催
    • 継続的な刷新を通してシステムを作り変えていく
    ポイントサービスのシステムを
    変更や保守がしやすいシステムへ

    View full-size slide

  59. ポイントチーム。採用やってます。
    70
    https://hrmos.co/pages/nifty/jobs/0000001

    View full-size slide

  60. Copyright ©NIFTY Corporation All Rights Reserved.
    ご清聴ありがとうございました
    71

    View full-size slide