©2022 RAKUS Co., Ltd. RDRA/DDD/Goで モジュラーモノリスの アプリを開発してみた話 株式会社ラクス 今本光 

自己紹介 SI企業でのエンジニア経験を経て 2021/10にラクスに入社。 SRE課所属 趣味:野球観戦、サウナ、日向坂46 Twitter: @imamotohikaru GitHub: @kudagonbe 

開発フェーズごとの戦略・アウトプット 要件定義 基本/詳細設計 実装 戦略 アウト プット RDRAを用いた要求分析 ・業務、BUCの洗い出し ・画面、システム機能の洗い出し ・要求元との要件合意の迅速化 RDRA資料を利用してDDD ・RDRAの業務分割を前提としたコン テキスト分割 ・RDRAと同じドメイン名 ・コンテキスト単位で設計資料作成 Goでモジュラーモノリス ・コンテキストごとに Go modulesを割 り当て(Workspace Mode使用) ・moduleごとにレイヤードアーキテク チャで実装 RDRAの 各種ダイアグラム コンテキストマップ コンテキストごとの 設計資料 Goプログラム 

開発フェーズごとの戦略・アウトプット 要件定義 基本/詳細設計 実装 戦略 アウト プット RDRAを用いた要求分析 ・業務、BUCの洗い出し ・画面、システム機能の洗い出し ・要求元との要件合意の迅速化 RDRA資料を利用してDDD ・RDRAの業務分割を前提としたコン テキスト分割 ・RDRAと同じドメイン名 ・コンテキスト単位で設計資料作成 Goでモジュラーモノリス ・コンテキストごとに Go modulesを割 り当て(Workspace Mode使用) ・moduleごとにレイヤードアーキテク チャで実装 RDRAの 各種ダイアグラム コンテキストマップ コンテキストごとの 設計資料 Goプログラム 

要件定義フェーズ 

RDRAを用いた要求分析 ● RDRA(リレーションシップ駆動要求分析)とは ○ 神崎善司さん(@zenzengood)が提唱している要件分析手法 ○ 上位の「レイヤー」から要求分析をスタートして、徐々に下位の「レイヤー」に 向けて要件を詳細化していく ○ レイヤーごとに「アイコン」というモデルを用いて「ダイアグラム」という成果 物を作成する 

RDRAに関する概念①：レイヤー システム価値 役割 具体的な 作業 システムが 「誰にとっての価値を 実現するのか」 を明らかにする 関連するアクター、 外部システム、 システム化目的等を定義 システム外部環境 システム境界 システム システムが 「どのように使われる のか」 を明らかにする システムと 「どう関わるか」 を明らかにする システムそのものを 表現する 業務、 ビジネスユースケースを洗 い出し、 業務フローや利用ケース を定義する 誰がどのようにシステムを 利用するか （画面・イベント）や システムの処理の単位 （ユースケース）を定義す る システム化する 「情報」と その情報が取り得る 「状態」で システムを明示する 上位 下位 レイヤー名 

上位レイヤーを入力として下位レイヤー作業を実施する システム価値 役割 具体的な 作業 システムが 「誰にとっての価値を 実現するのか」 を明らかにする 関連するアクター、 外部システム、 システム化目的等を定義 システム外部環境 システム境界 システム システムが 「どのように使われる のか」 を明らかにする システムと 「どう関わるか」 を明らかにする システムそのものを 表現する 業務、 ビジネスユースケースを洗 い出し、 業務フローや利用ケース を定義する 誰がどのようにシステムを 利用するか （画面・イベント）や システムの処理の単位 （ユースケース）を定義す る システム化する 「情報」と その情報が取り得る 「状態」で システムを明示する Input Input Input 上位 下位 レイヤー名 

上位レイヤーは下位レイヤーの「WHY」になっている システム価値 役割 具体的な 作業 システムが 「誰にとっての価値を 実現するのか」 を明らかにする 関連するアクター、 外部システム、 システム化目的等を定義 システム外部環境 システム境界 システム システムが 「どのように使われる のか」 を明らかにする システムと 「どう関わるか」 を明らかにする システムそのものを 表現する 業務、 ビジネスユースケースを洗 い出し、 業務フローや利用ケース を定義する 誰がどのようにシステムを 利用するか （画面・イベント）や システムの処理の単位 （ユースケース）を定義す る システム化する 「情報」と その情報が取り得る 「状態」で システムを明示する WHY WHY WHY 上位 下位 レイヤー名 

● アイコン ○ レイヤーごとに定義されるモデル ● ダイアグラム ○ レイヤーごと明らかにすべき事柄を 示すための図 ● 例：システムコンテキスト図 ○ システム価値レイヤーで定義されるダ イアグラム ○ システムに関わるアクター、外部シス テムをアイコンとして定義する ○ システム化の目的を認識合わせする RDRAに関する概念②：アイコン・ダイアグラム 

今回作成した ダイアグラム ● 「業務フロー+UC複合図」のみ複数 レイヤーを跨ぐダイアグラム ● draw.ioで作図し、 GoogleSpreadSheetに集約 ● それぞれの詳しい説明はRDRA2.0 ハンドブック 等をご参照ください。 

RDRAを実践してみた感想 ● 「要件定義」にとどまらず「基本設計」まで踏み込んだドキュメント が完成される ○ 内容が具体的になるので要求元との要件合意がより迅速・明確にできる ● 「業務」や「ビジネスユースケース」の分割は難しい ○ 試行錯誤して決定する必要がある ● ビジネスとシステムのバランス感覚が必要 ○ システムに寄りすぎると、ビジネス側の人に内容を理解してもらえない 

開発フェーズごとの戦略・アウトプット 要件定義 基本/詳細設計 実装 戦略 アウト プット RDRAを用いた要求分析 ・業務、BUCの洗い出し ・画面、システム機能の洗い出し ・要求元との要件合意の迅速化 RDRA資料を利用してDDD ・RDRAの業務分割を前提としたコン テキスト分割 ・RDRAと同じドメイン名 ・コンテキスト単位で設計資料作成 Goでモジュラーモノリス ・コンテキストごとに Go modulesを割 り当て(Workspace Mode使用) ・moduleごとにレイヤードアーキテク チャで実装 RDRAの 各種ダイアグラム コンテキストマップ コンテキストごとの 設計資料 Goプログラム 

基本/詳細設計フェーズ 

RDRA資料を利用してDDD 戦略的DDDを実践 ● コンテキストマップの作成 ○ RDRAの「ビジネスコンテキスト」「業務フロー+UC複合図」を主なインプットとして、 分割できる業務領域を洗い出して境界付けられたコンテキストを定義 ● ユビキタス言語となる用語集の作成 ○ RDRAの「情報モデル」を主なインプットとして、コンテキストごとに「用語説明」とい う形で主なユビキタス言語を付記 

コンテキストマップの イメージ コンテキストごとの名前・責務・情報・用語説明 を整理し、 コンテキスト間の依存関係を矢印で図示。 コンテキスト間が相互依存・循環参照にならな いようにコンテキストを分割する。 

コンテキストごとの設計資料 レイヤードアーキテクチャの各層に対応する資料を作成 （コンテキストごとにレイヤードアーキテクチャ構成をとる想定のため） ● Domain層 → ドメインモデル図 ● UserInterface層、Application層 → シーケンス図 ● Infrastructure層 → テーブル設計 

DDDを実践してみた感想 ● 前フェーズのRDRAの資料をインプットとして活用できた点が良かった ○ RDRAで基本設計まで踏み込んでいるので、モデリングがしやすかった ● テキストベースでの用語説明や設計意図説明も残しておいた方が良い ● mermaid.jsを使ってmarkdownファイル内で書いたので、レビューもし てもらいやすかった ○ GitHubがmermaidの自動レンダリングに対応している 

開発フェーズごとの戦略・アウトプット 要件定義 基本/詳細設計 実装 戦略 アウト プット RDRAを用いた要求分析 ・業務、BUCの洗い出し ・画面、システム機能の洗い出し ・要求元との要件合意の迅速化 RDRA資料を利用してDDD ・RDRAの業務分割を前提としたコン テキスト分割 ・RDRAと同じドメイン名 ・コンテキスト単位で設計資料作成 Goでモジュラーモノリス ・コンテキストごとに Go modulesを割 り当て(Workspace Mode使用) ・moduleごとにレイヤードアーキテク チャで実装 RDRAの 各種ダイアグラム コンテキストマップ コンテキストごとの 設計資料 Goプログラム 

実装フェーズ 

Goでモジュラーモノリス ● Goには「module」というコード管理 単位が存在 ● Workspace modeを利用し、複数 のmoduleをモノレポで管理するモ ジュラーモノリス構成を取る事が可能 Main Module Module A Module B Main Module Workspace 管理 

参考：GoのWorkspace mode ● Go1.18から導入 ● Moduleの解決をgo.workファイルに記述できる 

実装の基本方針 ● コンテキストマップと同じ粒度でGo Moduleを作成することで、モジュラーモ ノリスを実現する ○ Moduleの名前や依存関係はコンテキストマップを踏襲 ○ 1つのリポジトリ（モノレポ）で複数Moduleを管理し、同一リポジトリ内のModuleにも依存可能 ● Moduleごとにレイヤードアーキテクチャ構成にする ● コンテキストごとにDBも分割 ○ PostgreSQLで同一DBクラスタで複数DBを作成 ● その他の細かい実装方針は以下のStyleGuideでも公開しています ○ https://github.com/rakus-public/styleguide/tree/main/go 

未来の話：モジュラーモノリスをMSA化 ● MSA化する場合はModuleを別リポジトリに切り出すことで実現可能 ○ 切り出すModuleに対して外部呼び出し用のAPIを準備 ○ 切り出したModuleに対して行っていたメソッド呼び出しを、API呼び出しに切り替 える ○ DBは既に分離済みのため、大きなマイグレーション不要 

Goでモジュラーモノリスを実践してみた感想 ● DDDの境界づけられたコンテキストがソースコードにも対応づけられる ので、要件定義・基本/詳細設計フェーズとの一貫性が出て良かった ● モジュラーモノリス構成を実現するのにGoは適した言語だと思った ● GoでDDDを実践するための実装手法については手探りになる場面が 多く、今後もブラッシュアップが必要 

交通費・経費精算 システム 勤怠管理システム コールセンター向けCRM システム 問い合わせ管理 システム メールマーケティングサービ ス 販売管理業務 システム 電子請求書発行・電子保存 システム 社内向け AIチャットボット BtoB SaaSのマルチヒットメーカーとして成長中！ 企業の業務の効率化、付加価値化に貢献する複数のサービスを展開！ 

ご清聴ありがとうございました