リアーキテクチャxDDD 1年間の取り組みと進化

2024.11.06
DDDで複雑なシステムをリアーキテクチャをした1年の体験談withミライトデザイン

Transcript

1. © asken.inc リアーキテクチャxDDD 1年間の取り組みと進化 23/01/23 hsawaji
2. © asken.inc 2 自己紹介 asken でバックエンドエンジニアをしています。 - 2017年 asken にジョイン - 海外事業部でUS/Canada向けアプリのAPI開発 - 医療事業部で糖尿病患者向けアプリのAPI開発 - 国内事業部でアプリの価値検証とリアーキテクチャの推進 など、asken の色々なプロダクトに関わってきました。
3. © asken.inc 3 会社紹介
4. © asken.inc 4 プロダクト
5. © asken.inc 5 プロダクト
6. © asken.inc 6 背景 「あすけん」は今、17年間運用してきたシステムのリアーキテクチャを進めて います。約1年間リアーキテクチャをする中で色々な変化や課題に直面してきま した。今日は変化を起こした目的と、発生した課題、どう課題に対峙してきた かを振り返ります！ リアーキテクチャをしている人やこれからしようとしている人に参考になるこ とがあれば幸いです。
7. © asken.inc 7 なぜリアーキテクチャをしているのか？
8. © asken.inc 8 前提 我々が開発するどの機能が「ユーザの価値」になるかはわからない そのため「ユーザ価値」を発見するために、素早く機能をリリースして 価値の検証を行う必要がある 素早くリリースするために開発速度を上げていきたい
9. © asken.inc 9 リアーキテクチャの目的
10. © asken.inc 10 リアーキテクチャの目的
11. © asken.inc 11 リアーキテクチャの目的
12. © asken.inc 12 整理の方法 RDRA Relationship Driven Requirement Analysis ICONIX ユースケース駆動開発 DDD ドメイン駆動設計 サービスの構造を理解する 仕様を整理する サービスの仕様とコードを一致させる
13. © asken.inc 13 素早い仮説検証を行いユーザに価値を届け続ける そのために、変更しやすいシステムにしたい 具体的には、複雑で理解しづらくなってしまったコードを RDRA, ICONIX, DDD を使って整理し実装することで、コードを素早く理解し、安全に追加修正でき るようにする リアーキテクチャの目的
14. © asken.inc 14 2023年下期の振り返り 約1年前、プロダクト開発とは別にリアーキテクチャ専属のチームを編成した。 そのチームがリアーキテクチャをしながら開発に必要なものを整えていった。 リアーキテクチャチーム プロダクト開発チーム リアーキテクチャを担当 主にKotlinで開発 プロダクト開発を担当 主にPHPで開発
15. © asken.inc 15 2023年下期の振り返り 最初の半年間の成果として、1回目のリリースを行い プロセス、アーキテクチャ、開発環境など「開発の型」ができてきた
16. © asken.inc 16 2023年下期の振り返り 1回目のリリースまでの半年間で「開発の型」ができたので リアーキテクチャのやり方を広めて プロダクト開発の速度を早めていく準備が整った
17. © asken.inc 17 2024年上期のテーマ プロダクト開発を新アーキテクチャでやる
18. © asken.inc 18 ２つの軸
19. © asken.inc 19 ２つの軸
20. © asken.inc 20 既存機能開発でリアーキテクチャを進める
21. © asken.inc 21 リアーキテクチャが全て完了するには数年かかる... → 新アーキテクチャの効果を1日でも早く享受したい 目的 既存機能開発でリアーキテクチャを進める
22. © asken.inc 22 プロダクト開発するところをコアドメインと定め コアドメインからリアーキテクチャを進めた やったこと 既存機能開発でリアーキテクチャを進める これによって、2023年上期より複雑な機能の リアーキテクチャを進めることができた
23. © asken.inc 23 実践から得た学び
24. © asken.inc 24 とある機能開発... 既存機能開発でリアーキテクチャを進める リアーキテクチャと同じ様に RDRA/ICONIXを使ってサービスの仕様を整理 設計を行い、実装に進んだ
25. © asken.inc 25 発生した問題 既存機能開発でリアーキテクチャを進める 実装中に新たな仕様に気がついて手戻りが多発 結果... リリーススケジュールが何度も遅延した
26. © asken.inc 26 既存機能開発でリアーキテクチャを進める 振り返ってみると - 実装時にデータの新しいバリエーションに気がついた - 把握できていないデータ構造があった - システム都合のデータ更新パターン - サービス仕様から類推が難しいコード値、など というのが多かった
27. © asken.inc 27 既存機能開発でリアーキテクチャを進める データベースの構造とドメインモデルのマッピング がちゃんと整理できていなかった
28. © asken.inc 28 既存機能開発でリアーキテクチャを進める 今回のリアーキテクチャは データベースの構造を極力変えない方針にしている 理由①
29. © asken.inc 29 既存機能開発でリアーキテクチャを進める そのためRepository層を腐敗防止層として「データ ↔ ドメ イン」のマッピングを行なっている 複雑にマッピングしてドメインクラスたちを作っている 理由①
30. © asken.inc 30 既存機能開発でリアーキテクチャを進める 2023年度下期は 簡単な機能を中心にリアーキテクチャを実施しており問題が顕在 化しなかった 2024年度上期は 複雑なコアドメインに取り掛かったことで問題が顕在化した 理由①
31. © asken.inc 31 既存機能開発でリアーキテクチャを進める PHPの暗黙の型変換があり、ソースコードからは把握しづら かった データのバリエーションや仕様はソースコードを読むだけで は把握しづらかった 理由②
32. © asken.inc 32 既存機能開発でリアーキテクチャを進める こういうやつがいると データの仕様がとても分かりづらくなる 理由②
33. © asken.inc 33 既存機能開発でリアーキテクチャを進める RDRA/ICONIXの成果物だけでなく 別途データ仕様を整理する必要があった そうしないと、実装時に気が付き開発工数が膨れ上がる 学び
34. © asken.inc 34 改善
35. © asken.inc 35 既存機能開発でリアーキテクチャを進める 次の開発では詳細にデータ仕様をまとめていった かなり複雑なドメインを扱ったが大きな遅れもなく開発を完 了していた
36. © asken.inc 36 既存機能開発でリアーキテクチャを進める 詳細にデータ仕様をまとめることで、調査に時間がはかかっ たが、実装時に悩むことは少なかった → 実装時の手戻りが減るので スケジュールを把握しやすくなる
37. © asken.inc 37 既存機能開発でリアーキテクチャを進める いくら詳細に調査しても 後々になって気がつくことは避けられない それは早めのテストでカバーする
38. © asken.inc 既存機能の開発対象をリアーキテクチャする 学び 1. 既存サービスの仕様を把握する 2. データの仕様を把握する 3. サービスに合わせて設計をする 4. 実装をする ここにちゃんとコ ストをかける
39. © asken.inc 既存機能の開発対象をリアーキテクチャする 学び RDRA/ICONIXとは別に データのバリエーションや組み合わせの仕様をまとめる 事前にやることで、実装時の手戻りが減り 実装時のスケジュールを把握しやすくなる
40. © asken.inc 40 プロダクト開発に沿って進めることで コアドメインのリアーキテクチャは促進された 次の開発で恩恵を受けることができそう まとめ 既存機能の開発対象をリアーキテクチャする
41. © asken.inc 41 サービス仕様の他にデータ仕様を把握する必要がある RDRA/ICONIXだけではカバーできないので、別途まとめる 必要がある データ仕様を把握しておくと、実装時に手戻りが少なくなり スケジュールの把握がしやすくなる まとめ 既存機能の開発対象をリアーキテクチャする
42. © asken.inc 42 ２つの軸
43. © asken.inc 43 新規開発を新アーキテクチャでやる
44. © asken.inc 44 PHPは分かりづらい作りの上に、新しい機能を追加しても、 そのうちKotlinにリアーキテクチャされる → 最初からアーキテクチャが整理されているKotlinで作れば リアーキテクチャの必要もなく開発を早く進められる 目的 新規開発を新アーキテクチャでやる
45. © asken.inc 45 リアーキテクチャと同じ様に進めた きっちりとRDRA/ICONIXで分析して、設計を経て開発を 行った いくつかの機能が新アーキテクチャで作られリリースされて いる やったこと 新規開発を新アーキテクチャでやる
46. © asken.inc 46 実践から得た学び
47. © asken.inc 47 開発も完了し、無事リリースされた... が...検証の結果...作成した機能が廃止された 新規開発を新アーキテクチャでやる
48. © asken.inc 48 新規開発はリリース後にA/Bテストでの価値検証をしている 新規機能開発と既存PHPのリアーキテクチャとの違いは A/Bテストの結果によって機能が廃止される可能性があると いうところ 新規開発を新アーキテクチャでやる 問題点
49. © asken.inc 49 廃止される可能性のある機能を どこまで時間をかけて開発すれば良いのだろうか？ 新規開発を新アーキテクチャでやる
50. © asken.inc 50 新規開発はその後のA/Bテストで廃止になる可能性がある 選択肢はいくつか思い浮かんでいるが まだ答えは出ていない ・一旦トランザクションスクリプトで実装する ・分析フェーズを簡略化し、実装速度の早い設計にする ・リアーキテクチャと同様に設計実装する 新規開発を新アーキテクチャでやる
51. © asken.inc 51 新規開発はその後のA/Bテストで廃止になる可能性がある 選択肢はいくつか思い浮かんでいるが まだ答えは出ていない ・一旦トランザクションスクリプトで実装する ・分析フェーズを簡略化し、実装速度の早い設計にする ・リアーキテクチャと同様に設計実装する 新規開発を新アーキテクチャでやる このあたりが 現実解だと 思っている
52. © asken.inc 52 まとめ
53. © asken.inc まとめ 実践したこと - 既存機能の改修と同時にリアーキを進める - 新規機能開発を新アーキテクチャで行うことを必須にする 成果 - コアドメインのリアーキテクチャが進んだ - 新規機能開発は全て新アーキテクチャで実装された
54. © asken.inc まとめ うまく行った秘訣 2023年下期のリアーキテクチャチームを分割しプロダクト開発チームに 配置することで知識の共有を行なった → 時間の都合もあり別の機会に...
55. © asken.inc まとめ うまくいかなかったこと - コアドメインの開発で実装時に判明する仕様があり、開発に遅れが生じてしまった - 時間をかけて作ったものがA/Bテストの結果で廃止になってしまった 学び - RDRA/ICONIXだけでは整理しきれない情報がある - 特にデータ仕様周りがソースから把握しづらいのでコストを掛けて理解をする - 結果的に開発完了までの期間は早くなる - 新規開発機能はA/Bテストの結果によって廃止される可能性がある - どのように進めていくかは今後の課題としている
56. © asken.inc 今後の展望 今後は、より早くリアーキテクチャを進め、その効果を受けられるように、下 記のような点を進めていこうとしています。 - プロダクト開発を行う予定の機能を先にリアーキテクチャする - ロードマップから逆算してリアーキテクチャを実施する - 最初の価値検証から新リアーキでできるようにする - 新規開発を新アーキテクチャで行う際の設計方法の確立 - 価値検証を早く回すためにちょうどよい方法を定める
57. © asken.inc 57 Thank you!