ビジネスの構造をアーキテクチャに落と し込みソフトウェアに可変性を注入する 2024/5/22 株式会社MonotaRO CTO 普川泰如 1 © 2022 MonotaRO Co., Ltd. All Rights Reserved. モノタロウ基幹システム刷新の実践例

● イベントストーミングは、特に業務側メンバー（ドメインエキスパー ト）と問題空間を共有するのにとても有効 ● ただし実際にモデルを洗練させるためには抽象度を変えて段階的に関心 の分離を行う ● 他の手法も使いながらモデリングを洗練させていく ● モデリングした分析結果から、業務の変更パターンを見える化しそれを アーキテクチャに落とし込むことで、ソフトウェア・業務に可変性を持 たせることができる（はず） 2 今日の話の要約

3 モノタロウでドメインモデリン グを行う背景

システムと組織 4 BtoB を対象に、 自ら間接資材の在庫を持ち、 自らオンラインで売るEC企業 コールセンター、商 品 採 用、物 流、 マーケティング、データサイエンス、 IT など多くの業務とシステムを 自社開発、自社運用もしている フルスタック EC カンパニー 事業紹介

システムと組織 5 事業紹介 商品点数 2,217万点 ユーザー数 約910万件 売上（連結） 2542億円 グローバルに サービス展開 　※前年比 +12.5%

わたしたちについて 6 事業成長サイクル 取扱商品 点数拡大 顧客数拡大 在庫点数 拡大 売上・利益 拡大 スケールアップ=利便性アップ •新規顧客獲得増 •ロングテール商品の購入頻度向上 •商品の在庫化が進むことによって 納期短縮、利便性向上 •プライベートブランド化も 推進し利益率向上 •検索ワード数拡大 •ワンストップショッピングの幅拡大 （取扱商品点数2,217万点） •周辺商品の取扱拡大

わたしたちについて 7 売上・登録口座数推移 売上は順調に増加 その裏でサービス、機 能、顧客の増加により 業務の複雑性も増加 売上2,000億円 突破 2009.12 東証一部変更 2006.12 マザーズ上場 (計画値) （百万円） （千口座）

8 モノタロウのビジネスモデル 事業成長サイクルのも と、商品数、顧客数、注 文数が増加、それにとも なって図の各ネットワー クも拡大していく。 結果、トランザクション 数と複雑性が増す。ドメ インロジックも激増。各 領域毎にスケールできる 状況にしていきたい。

9 ２つの複雑性 我々が提供しているサービスは高度化していく中で差別化となる必要な業務の複雑性に長 年のビジネス/組織の拡大によって生じた不要な複雑性が付随し、本来取り組むべき課題、 複雑性に集中できなくなっていることが問題。これを取り除き、業務とシステムの可変性 を再び取り戻すことが必要 っっｘ 取り組むべ き課題 不必要な複雑性、 煩雑さ 以前 現状 現状 現状 未来 っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ 不必要な複雑性が増え た結果、本来取り組むべ き課題に集中できない 課題を分割すること、不必要な煩雑さ を減らすことで、本来取り組むべき課 題に向き合える状態になる

10 課題と取り組み内容まとめ ● 基幹システムがモノリスアプリケーションであり、拡張とビジネス成 長によって複雑さが増し、変更容易性が失われた。 ● 一方で業務のスケールとそれに付随する「複雑性」はモノタロウの差 別化ポイントでもある ● 継続的な会社の成長のため競争優位の源泉となる複雑性を改めて構造 的に理解をする。 ● その複雑性をアーキテクチャの構造に落とし込むことで、業務とソフ トウェアの可変性を担保し、会社の成長につなげていくことを行う ● アーキテクチャ設計が事業要求に根ざしたものにすることが重要

11 ドメインモデリング① ドメイン分割と イベントストーミング

● 協働的にドメインのモデリングを行うワークショップの1手法 ● ドメインエキスパート(業務側)とエンジニア(システム側)が一緒に行う ● ワークの結果がソフトウェア設計のインプットになる 12 イベントストーミングとは

1. ドメインイベントを洗い出す 2. 時系列に並べる 3. 分割点となるイベント(ピボタルイベント)をマークする 4. 並行処理を見つける 5. 関係者・外部システムを洗い出す 6. 前から読み上げて曖昧なところがないか検証する 7. グループや集約、ドメイン境界(境界づけられたコンテキスト)を検討する 8. イベントストーミング全体を通じて、業務の認識や言葉の違い・新たな発見がなされる 13 イベントストーミングの進め方 より詳細が知りたい方はAWSのSA福井さんの以下の動画がおすすめ 実践！モノリスからマイクロサービス！ Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo

● ステークホルダー全員の共通認識のもと分析されたビジネスプロセスが可視化される ○ ドメイン・集約 = 関心事の凝集 ○ 境界づけられたコンテキスト = 関心事の分離 ○ ユビキタス言語 = 言葉の統一による共通認識の深化 ● ドメインモデルが、システム設計のインプットになる ○ ドメインモデル = (レイヤード|ヘキサゴナル|オニオン)アーキテクチャにおけるド メイン層の実装そのもの ● 得られるメリット ○ 業務側・システム側の共通理解がそのままシステムに反映される ○ 関心事が分離されているので、各システムが独立して変化できる 14 まとめると

● 仮決めしたドメインにそって組織を再編した。（逆コンウェイ戦略） ● 既存アプリケーションをコンポーネント毎にオーナードメインを決めた ● ドメインチーム毎にアプリケーションの実行環境分けた 15 ドメインモデリングの前にやったこと

まずは業務全体を広範囲にイベントストーミング エンジニア、業務担当者、マネージャーなど総勢30名ほど参加し、全体感を共有 ただしこれだけでは、システムの設計からはほど遠い。。。。 Step1　業務全体でのイベントストーミング Web注文 キャンセル 受注保留 引当て 出荷指示 調達 出荷 配送

17 受注/配送ドメイン境界議論 Step2 特定のの領域でさらに分析 特に受注/配送ドメイン境界が曖昧だっ たため議論を深めた。 この議論を通じて、受注ドメインの責 務について論点出しができた。 受注 引当 在庫 出荷 ※これもあくまで１トピックで他の境 界や業務整理が必要なところについて 随時、分析を加えていっています

ビジネスドメイン全体から詳細度を上げ分析をする モノリス アプリケーション 大まかな ドメイン境界の発見 境界づけられた コンテキスト 洗練された ドメインモデル Big Picture 要素の洗い出し ソフトウェ アデザイン 構造化 プロセス・モ デリング 要素の関連付け Big Picture 要素の洗い出し ソフト ウェアデ ザイン 構造化 プロセス ・モデリ ング 要素の関連付け Big Picture 要素の洗い出し ソフト ウェアデ ザイン 構造化 プロセス ・モデリ ング 要素の関連付け 一度に全てを把握することは不可能。全体から入りつつ、段階的な関心の分離を行っていく 必要がある。抽象度を下げながらそれをサイクリックに進めていくことが必要

やってみてわかったこと ● イベントストーミングでは、複数の関係者が課題認識や前提を作るのはかなり有効 ● 1回のイベントストーミングは半日から１日程度。ただしそれで終わりではない ● 最初は業務全体を対象に、その後詳細度を上げて特定の領域で行っていく ● 結果、分析自体はかなり時間と期間がかかる。実際に我々は大まかなドメイン境界を決め、 実装のPoC開始まで５ヶ月程度かけている。(専任メンバー＋関係者） ● ソフトウェア設計に落とし込むにはイベントストーミングだけではギャップがあり、他にも 様々なワークでモデルを洗練させていく（後述） ● モデリングのセオリーはあるがそれを全部やる時間はなく、必要に応じて領域と手法を変え て探索的にモデルを深めていく必要があり、かなり高度な判断となる 19 ドメインモデリングを行っての実際

何度も実施することで共通する考え方、質問が身についた ● そのドメイン・エンティティの責務は何か ● 集約が大きすぎないか、分けられる点はないか ● 別々のコンテキストで登場する同じ名前のものがまったく同じ値を指しているか ● エンティティや属性、振る舞いの名前が適切か ● 一回の分析やワークで全てを決めきらない。その後の別の観点での整合性を検証しなが ら、決まっていく 基本的に関心事の凝集・分離・ユビキタス言語の発見など、イベントストーミングで説明され ている基本が重要 20 ドメインモデリング進め方のポイント

21 ドメインモデリング② 在庫ドメインモデリングの具体例

ここに「Stock 在庫」があるが、 これは在庫数管理業務ではなく在庫計画などの戦略的な業務 ● そもそもモノタロウにおける在庫数管理業務は、受注，配送，発注，倉庫といった 周辺業務の中に溶け込んでおり、ドメインとして確立していない ● システム構築当初の「小さいモノリスアプリ」として考えると、 業務に必要な関心事を自ら持つことは一定の合理性があった ● 「在庫」が複数のドメインとの密接な結合点であるため、難易度は高いがここを最 初に整理すると判断 22 在庫ドメインの分析を最初のターゲットにした

● ビジネスの成長とともにシステムも徐々に大きくなっていき変更を加えた結 果、在庫状況TBLは神テーブルとなり周辺業務の密結合点となり果ててしまっ た。特に以下３つの課題がクリティカルであった ● 課題１：在庫数管理とは本来無関係な周辺業務の属性をTBLに多数追加された （受発注／入出荷保留数など）　→属性の本来の責務のドメインの特定 ● 課題２：システムの成長によりテーブルへのカラム追加が難しくなった。結 果、在庫管理がもつべき属性を別のテーブルやアプリケーションのロジックで もつこととなった（出庫余力など）　→参照レイヤーを更新と分離させる ● 課題３：テーブルの更新がUPdateでおこなわれるため履歴情報が一箇所に残っ ていない→履歴を残す必要がある 神テーブルの爆誕と顕在化した課題 23

● 在庫管理システムのメインの責務は商品の入庫と出庫の数と理由の管理。その在庫の状態 の変更イベントの変更は少ない（ただし集約の必要はある）一方在庫ドメインで取り扱う 属性数が多く、また継続的に追加される 24 在庫業務の構造１　取り扱う属性数が多い 発注ドメイン 在庫ドメイン 配送ドメイン 発注 入荷 引当 出荷 ここの変更、追加要求 が多い 商品が入る

出庫 余力 入庫残数 （入荷予定数） 狭義の在庫管理システムは品物の出入りの数と理由の管理。一方で他ドメインから、様々な「在 庫数」を参照ニーズがある。そしてどういう数を参照したいかは業務・ユースケースによって異 なる。→可変性の大きい部分 25 在庫業務の構造２　業務によって必要とする「在庫数」が異なる 引当済数 出庫残数 出庫残数 （出庫予定） 現在 在庫数 予定 在庫数 引当 可能数 在庫数内訳 在庫されている商品のうち、調整なく動かせる数 販売可能数

● 在庫状況TBLの属性（カラム）毎に参照、更新のユースケースを分析。コンテキス トマップを作成 ● さらに整理を進め、徐々に在庫ドメインの姿が明確になる 26 データモデリングによって属性の整理を実施 発注 在庫 倉庫間輸送

● 仮想コードで在庫ドメインの実装や命名のイメージを固める ● 関係者総出でモブプロを見守り認識合わせ ● シーケンス図で周辺ドメインとのメッセージングを検証 ● さらにドメインモデルを洗練させる 27 ドメインモデルを洗練させる

28 ドメインモデルを洗練させるためにやったこと ● ドメインモデルを洗練させるとは「深いドメイン知識」をモデルに反映していくこと ● そのためには色々な観点でモデルを解釈、整合がされるようにマッピングさせること が重要 観点 ワークショップ例 既存 AS-IS 業務 ● 業務プロセス分析 ● シーケンス分析 ソフトウェア ● 既存データモデリング分析 ● 既存コンポーネント分析 新 To-Be 業務 ● バリューストリームマッピング ● ドメインビジョン定義 ソフトウェア ● プロトタイピング ● システムアーキテクチャ

● イベントストーミング ○ 問題空間の概要をシステム側業務側全員で把握できる。ユビキタス言語の獲得 ● データモデルの分析 ○ 既存のデータモデルから集約を抽出し整理をする。既存システムとのマッピングが しやすい ● シーケンス分析 ○ 色々な業務のユースケースを考慮してみることでモデリングが洗練される ● 仮想コード ○ コードに落とし込むことで実装観点での矛盾、開発者のドメイン知識獲得も行える 29 モデリングで我々がよく行ったワーク

● 可変性が必要な他ドメインへのリードモデルをコマンドから分離、また在庫の出入りを履 歴として残すという要求から、CQRS＋ESをベースに設計 ● 段階的に実証を進めている。 30 いよいよプロトタイピング

31 ビジネスの構造をアーキテクチャに落とし込み ソフトウェアに可変性を注入する(ぞ) ドメインモデリングのアウトプット（導出された境界、イベント、集約、属性）を ソフトウェア設計の文脈で整理を行った リードモデル ドメインロ ジック 業務イベント

● 業務側メンバーとの体制構築や知見をモデリングに反映の仕方 ● ドメインオーナーの獲得（ドメインビジョン、あるべき姿Tobeをどうモデルに反映 させるか） ● モデリング結果を既存システムに段階的に適用の仕方、移行方法 ● アーキテクチャ、ソースコードレベルでのモデリング適用例 32 今日の話で触れなかったこと

● イベントストーミングは、特に業務側メンバー（ドメインエキスパー ト）と問題空間を共有するのにとても有効 ● ただし実際にモデルを洗練させるためには抽象度を変えて段階的に関心 の分離を行う ● 他の手法も使いながらモデリングを洗練させていく ● モデリングした分析結果から、業務の変更パターンを見える化しそれを アーキテクチャに落とし込むことで、ソフトウェア・業務に可変性を持 たせることができる（はず） 33 まとめ（再掲）

● この発表資料のベースとなっているテックブログ記事 34 参考情報

エンジニア募集中 本社(大阪)/東京オフィス(赤坂) 35