「asken withミライトデザインのDDDのはじめ方 DDD x RDRA x ICONIX」に参加してきました
2023年9月14日（木）に開催された『asken withミライトデザインのDDDのはじめ方 DDD x RDRA x ICONIX』に参加してきたので、その内容を共有します。
（2023/10/6（金）追記）
動画が公開されていたので、リンクを各聴講メモに記載しました。
おことわり
この内容は非公式なものであり、自分なりに整理したものです。
「こんなこと言っているんだな～」と思ってみていただければと<(_ _)>
以下の内容には誤りが含まれる可能性があります。
間違っている部分などがあれば、コメントお願いします。
イベントについて
株式会社askenが現在取り組んでいるアーキテクチャ見直しとシステム再設計活動について、導入背景と現状、取り組み内容および学びを共有する会でした。
以下、概要です。
今「あすけん」は大きなチャレンジをしています。
中長期的なサービスの成長を見据えて、アーキテクチャの見直しとシステムの再設計を行っています。 この再設計の一環として、PHPで構築された既存システムをKotlinを用いた新システムに置き換えるという大きな決断をしました。
さらに、より保守性の高いシステムを目指して、新しい手法も試しています。 具体的には「ドメイン駆動設計(DDD)」を中心として「RDRA」「ICONIX」の考え方を取り入れ、業務の再分析、システムの再設計、再構築を行っています。
このチャレンジを成功させるために、これらの手法に対する多くの知見を持つ株式会社ミライトデザイン(以下ミライト)様にコンサルとしてジョインしていただき、askenエンジニアと共に、システム、プロセス再構築にご協力いただいております。
我々のチャレンジの内容について、推進者、マネジメント、コンサルタントといった複数の視点からご紹介します。今後DDDを始めたいと思っている方、現在DDDにチャレンジしているものの改善策を探している方のヒントになれば幸いです。
聴講メモ
リアーキテクチャとDDD導入背景
リアーキテクチャ実施とDDD導入の背景と現状を共有していただきました。
背景と要因
リリース期間が理想より3~6倍かかっている
要因
影響箇所の特定に時間が掛かっている
サービス構造とシステム構造が一致しておらず、システム理解に時間がかかる
一部サービス仕様がない
対応
サービス構造とシステム構造を一致させる
ドメインモデルを用いた開発スタイルにする（DDD導入）
言語フレームワークを変える
PHP ⇒ Kotlin Spring
サービス使用をまとめる
RDRAやICONIXを活用して、サービスを明確にする
リアーキテクチャとDDD導入時に気を付けたこと
ゴール：いいシステムかつ早く終わらせたい
ドメインに集中
DDDの知見があるメンバーと共に実践する
社内ににいなかったため、社外（株式会社ミライトデザイン）から知見のある人を呼んだ
初期段階から検証を実施する
モデル検証を初期から実施し、手戻り工数を抑える
PoCを3回実施
シンプル化
ドメインエキスパートと会話することを重視
ドメインモデルやユースケースもレビューしてもらう
段階的にリリース
優先順位を決めて、リリースし、FBをもらう
現状
モデリングと検証は実施済み
今は段階的リリースの計画を立てている
ドメインを中心にしたプロダクト開発
リアーキテクチャとDDD導入で取り組んでいることとその際に気を付けるべき点について、共有していただきました。
リアーキテクチャの現実
すべてを作り直すことはできないケースがある
データ構造にいきなり手を入れられないケースがある
効果測定をしたくても既存システムにその仕組みがない
リニューアルの成功は何か
既存課題が解決できること
潜在課題に対処できること（将来、顕在化しそうな課題）
現状、効果を定量的に測る仕組みがない
可視化するにはまた別のコストがかかる
PoCを実施し、定性的判断をしてもらう
デプロイが楽
修正、機能追加が容易
ソースコードが理解しやすくなった
進める上で意識していること
教条主義にならない
教科書そのまま適用するのではなく、現場に合わせてカスタマイズする
QCDSのSを重視する
Quality（品質）
Cost（コスト、予算）
Delivery（デリバリー）
Scope（スコープ）
スコープを明確にすることに注力する
そのためには、ドメインを理解しなければならない
何をなぜ作るか明確にする
何を作れば良いかわからないまま何かを作っている
改めてフロー整理、どのユースケース、どの業務フローと結びついている機能かを明確にしていく
各ソースコード、業務に繋がっている
進め方
知る→作るというプロセスを回す
課題を発見→あるべき姿を構築
ドメインを理解→ドメインを表現したプロダクトを構築
制約を知る→現場に合わせる≒現実解
実際の取り組み
業務と関連するユースケースの洗い出し
RDRAを活用して、業務とユースケースの整合とる
PoC期間に実装検証する対象のユースケースを選定する
概念モデル作成
アーキテクチャの検討
ユースケースから詳細までの流れ確認
ICONIXのプロセスを活用
Kotlinで実装
実装時に以下を確認
選定技術の運用性
開発フロー
チームに浸透しそうか
今後の課題
既存データモデルによる制約
データモデルの変更が行えない
非機能性
PoC以降のチームビルド
リアーキテクチャによってどうなりたいか
レイヤー・パッケージ・クラスの分け方についてのお話でした。
コードを分ける目的
ビジネスとコードを連動させたい
システムはビジネスのためにある
ドメインで共有
ビジネスのコードをパッケージに入れると良い
早く開発できるようにしたい
関係ないコードまで調べるのは手間がかかる
ドメインとDBの構造を分ける
ドメインの構造とDBのデータ構造は一致しない
手続きとDB操作も分けた方が良い
一緒にするとコード理解に時間が掛かり、開発スピードが落ちる
Repository
リポジトリは集約だけ扱うようにする
リポジトリの読み書きは明確に分ける
書く単位と読む単位が違う
RDRA,ICONIX,DDDから得た学び
RDRA、ICONIX、DDDを導入して、得た学びを共有
RDRA
勉強会の動画や書籍を参考に学習しながら実践
既存のシステムに影響されることなく、ユースケースを洗い出すことができた
概念モデル
miroを使って、実践
10時間のワークショップを開催
システムがどうあるべきかの共通認識を持てた
ドメイン知識の伝達をスムーズにできた
システムの複雑な箇所を可視化できた
ドメインエキスパートとも同じ資料で会話できた
用語と寒冷性の情報のため、エンジニア以外も理解しやすい
ICONIX
ユースケース記述部分のみ実践
今まで見えていなかった概念を発見し、それをドメインモデルに反映することができた
DDD
概念モデルとユースケース記述をベースにドメインモデルを作成
実装を行い、フィードバックを実施する
知識、アイデア、モデルの欠陥
ドメインモデルを作成することで、全体を見渡せるようになった
修正が行いやすくなった
参加してみての感想
私もRDRAを少し活用しているため、他に実践している人の声を聞けて良かったです。
概念モデルは業務概念を一枚絵で表現できるのが良いなと感じたため、現場でも試してみようかなと思います。
ドメインモデルはさわり程度の知識しかありませんでしたが、今回ですこし理解を深らめれたかなと思います。