Slide 1

Slide 1 text

© asken.inc RDRA, ICONIX, DDDの実践から得た学び 23/09/14 asken hsawaji

Slide 2

Slide 2 text

© asken.inc 2 背景 「あすけん」のサービスをリアーキテクチャするために、約5ヶ月間、技術検証を行って きました。 この検証では、既存システムを対象に分析から実装まで一通り行いました。その際、 RDRA, ICONIX, DDDなどの手法を活用して進めてきました。 今回は、各手法をどの用に使ったのか、どのような学びが合ったのかを紹介したいと 思います。

Slide 3

Slide 3 text

© asken.inc 3 自己紹介 askenでバックエンドエンジニアをやっています。 海外事業部にいたり、医療事業部にいたりして、 今は国内事業部でシステムのリアーキテクチャを推進しています。 askenではずっとPHPを触っていましたが今回のリアーキテクチャからKotlinを触るよ うになりました。 設計とアーキテクチャの勉強中です。

Slide 4

Slide 4 text

© asken.inc 4 テックブログも書いています PHPからKotlinへ、ドメイン駆動設計を用いたリアーキテクチャへの挑戦 https://tech.asken.inc/entry/2023/08/10/170000 より良い設計にするための勉強会を行いました https://tech.asken.inc/entry/2022/03/30/180000 Slackで「マルチチャンネルゲスト」のGithub通知を改善しました https://tech.asken.inc/entry/2022/10/07/170000

Slide 5

Slide 5 text

© asken.inc 5 スタート時点の私 RDRA - 「RDRAハンドブック2.0」は読んだ - 用語はざっくりと理解している - 実践した経験はない ICONIX - 「ユースケース駆動開発実践ガイド」は未読 - 用語はいくつか聞いたことがある - 実践した経験はない DDD - 「エヴァンス本」は読んだ - 社内の勉強会で学んだ - 用語と概要くらいはわかる - 実践した経験はない

Slide 6

Slide 6 text

© asken.inc 6 RDRA

Slide 7

Slide 7 text

© asken.inc 7 スプレッドシート版のRDRAを使用しました。 このスプレッドシートは、左のシートから順番に埋めていくことで、RDRAの 工程を進めてられるような構成になっています。 スプレッドシート版のRDRA: http://vsa.co.jp/rdratool/rdragraph0.7/RDRAToolDoc.pdf

Slide 8

Slide 8 text

© asken.inc 8 スプレッドシート版RDRAは下記のようなような流れで使い方を覚えました - ミライトデザインさんのRDRAワークショップの勉強会動画を見る - 参考: 【RDRA × AI】AI時代の要件定義ワークショップ【ペチオブ】 - https://www.youtube.com/watch?v=IfEu2KE7_5U - RDRAハンドブック2.0を見直しながらスプレッドシートと対応させていく

Slide 9

Slide 9 text

© asken.inc 9 食事記録 - ビジネスユースケース(BUC) - アクティビティ - ユースケース(UC) - 情報 - アクター

Slide 10

Slide 10 text

© asken.inc 10 食事記録 目的達成までの ユーザの動き システムの動作 ユーザの目的 「情報」はエンティティ 対象ユーザ 左から記載していく

Slide 11

Slide 11 text

© asken.inc 11 あすけん会員 (アクティビティ) システム (UC) 食品検索 食事記録 分量変更 キーワード 検索を行う 食事記録を 保存する 食事記録の分量を 更新する 食品選択 食事を記録しよう (BUC) データ (情報) 食品マスタ 食事記録 あすけん会員 (アクター)

Slide 12

Slide 12 text

© asken.inc 12 効果 RDRAではユースケースをアクティビティから分析するので、既存のシステム に影響されることなくユースケースを洗い出すことができた 複数のユースケースが含まれていたControllerも ユースケース毎にクラスが切り出され処理がわかりやすくなった

Slide 13

Slide 13 text

© asken.inc Controller 13 Controller UseCase1 クラス UseCase2 クラス UseCase1.処理() UseCase2.処理() UseCase1の処理 UseCase2の処理 UseCase1’の処理 UseCase3の処理 UseCase2’の処理 UseCase3.処理() UseCase3 クラス

Slide 14

Slide 14 text

© asken.inc 14 概念モデル

Slide 15

Slide 15 text

© asken.inc 15 設計に入る前に、既存システムの構成要素と各要素の関係を整理するために 「概念モデル」を作ることにしました 合計10時間ほど時間をかけて、全員でワークショップを行なった

Slide 16

Slide 16 text

© asken.inc 16 ワークショップはMiroを使って下記のような流れで行なった 1. 要素を付箋を書きながら周辺の業務知識を説明していく 2. 疑問点は都度質問を受けて付箋を使って説明をしていく 3. モデリングの観点で議論しながら付箋を修正していく

Slide 17

Slide 17 text

© asken.inc 17

Slide 18

Slide 18 text

© asken.inc 18 効果 - システムが「どうあるべきか」の共通認識が持てた - 既存システムがどうなっているかではなく「どうあるべきか」話すことができた - ドメイン知識の伝達ができた - 概念に関連する知識を網羅的に説明できた - 質問を受けることで「暗黙的な知識」も説明できた - システムの複雑な箇所が可視化された - システムの複雑な所に対して検証を行うことができた - 概念と説明を同じ資料にまとめたので後で参照しやすくなった - 質問などで前提を説明する必要がなくなった - ドメインエキスパートとも同じ資料で会話ができた - 用語と関連性の情報なのでエンジニア以外も理解がしやすい

Slide 19

Slide 19 text

© asken.inc 19 チームで「概念モデル」を一緒に作ることにより素早く共通認識を作る事がで きた、出来上がったもと同じくらい過程も大切だと感じた このワークショップは、その後の開発をスムーズに行うために効果的だった

Slide 20

Slide 20 text

© asken.inc 20 ICONIX / ユースケース記述

Slide 21

Slide 21 text

© asken.inc 21 RDRAで洗い出したユースケースに対して、ユースケース記述をつくる ユースケース記述は、ユーザの操作とシステムの処理を数行で記載する

Slide 22

Slide 22 text

© asken.inc 22 ユーザの動作と システムの処理 代替コースは途中で 処理が終了するもの

Slide 23

Slide 23 text

© asken.inc 23 振る舞い モデルに必要な用語 ドメインモデルに反映 ドメインモデルに反映

Slide 24

Slide 24 text

© asken.inc 24 ユースケースを具体的に記述することで、見えていなかった概念が見えてくる それをドメインモデルに反映することで良いモデルにアップデートできる 必要な振る舞いがわかることで、クラス設計の足がかりになる 効果

Slide 25

Slide 25 text

© asken.inc 25 DDD (クラス設計 ~ 実装)

Slide 26

Slide 26 text

© asken.inc 26 分析を元に設計する 概念モデル ドメイン モデル ユースケース 記述 クラスの 分け方 クラスの 振る舞い

Slide 27

Slide 27 text

© asken.inc 27 設計を元に実装する 概念モデル ドメイン モデル ユースケース 記述 クラスの 分け方 クラスの 振る舞い ソースコード 実装

Slide 28

Slide 28 text

© asken.inc 28 実装の結果でモデルを更新する 概念モデル ドメイン モデル ユースケース 記述 クラスの 分け方 クラスの 振る舞い ソースコード 実装 フィードバック

Slide 29

Slide 29 text

© asken.inc 29 実装中に得られる情報 - 実装することで得られた知識 - 新しく思いついたアイデア - モデルの欠陥 (実装できない・情報が取れない) 実装を進めていくと、ドメインモデルがどんどん変わっていく 実装しながらドメインモデルも洗練していく アイデアを素早く確認するためにドメインモデルを使用する

Slide 30

Slide 30 text

© asken.inc 30 DDDを使うメリット - 実装からドメインモデルにフィードバックをするメリット - ドメインモデルの検証を実装で行なう - 実装することで、ドメインモデルの矛盾点や欠陥が明らかになる - ドメインモデルを使うメリット - 設計の良し悪しはドメインモデルで全体を見たほうが分かりやすい - 視覚的に分かりやすいので、設計の議論をする際に共通認識を取りやすい - 簡単に変更できるので、レビューと修正がしやすい

Slide 31

Slide 31 text

© asken.inc 31 まとめ 今回の技術検証では RDRA、ICONIX、DDDを1つ1つ丁寧に行うことで、それぞ れの成果物が実装に繋がっている感覚を得ることができた 概念モデルは、素早く共通認識を作ることができ、非常に有効なものであった その概念モデルからドメインモデルを作るので、認識のズレが少なく設計の議 論ができたと感じている

Slide 32

Slide 32 text

© asken.inc 32 成果物のつながりのモデル

Slide 33

Slide 33 text

© asken.inc 33 スタート時点の私 RDRA - 「RDRAハンドブック2.0」は読んだ - 用語はざっくりと理解している - 実践した経験はない ICONIX - 「ユースケース駆動開発実践ガイド」は読んでいない - 用語はいくつか聞いたことがある - 実践した経験はない DDD - 「エヴァンス本」は読んだ - 社内の勉強会で学んだ - 用語と概要くらいはわかる - 実践した経験はない

Slide 34

Slide 34 text

© asken.inc 34 今の私 RDRA - RDRAの各要素の意味を理解した - 業務フローを意識して RDRAで分析できるようになった - 既存システムに影響されないユースケースの分析ができるようになった ICONIX - ユースケース記述とモデルの関係性を理解した - ユースケース記述を設計に繋げられるようになった DDD - モデルと実装のフィードバックループの利点を理解した - ドメインモデルを中心とした開発を実践できるようになった

Slide 35

Slide 35 text

© asken.inc 35 この5ヶ月間で業務をモデル化してソースコードで検証する方法を学ぶことが出 来ました。 これらの方法を使って、リアーキテクチャを確実に前に進められるようになっ たと思います。 まだまだ勉強中ですが、頑張っていきます。

Slide 36

Slide 36 text

© asken.inc 36 ご清聴ありがとうございました