見出し画像

「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を少し活用しているため、他に実践している人の声を聞けて良かったです。
概念モデルは業務概念を一枚絵で表現できるのが良いなと感じたため、現場でも試してみようかなと思います。
ドメインモデルはさわり程度の知識しかありませんでしたが、今回ですこし理解を深らめれたかなと思います。

参考

本イベントのConnpassグループについて

この記事が気に入ったらサポートをしてみませんか?