業務理解の深化と実践～ドメインモデリングで基幹システムを捉える

2025.2.13 Developers Summit 13-A-7

Transcript

1. 業務理解の深化と実践 ～ドメインモデリングで基幹システムを捉える 2025/2/13 株式会社MonotaRO 尾髙敏之 1 © 2024 MonotaRO Co., Ltd. All Rights Reserved.
2. 尾髙 敏之 株式会社MonotaRO CTO-Officeグループ 在庫モダナイズチーム シニアアーキテクト 2 2023年11月にモノタロウ入社。 IT職歴の大半を事業会社のIT部門で過ごし、biz/sysの関係構築や要件定義などの超上流 工程に取り組んできたが、「質とスピード」という言葉に出会ってからは品質→保守性 に目を開き、モノタロウ入社後は良い構造とは？を求めてチームとすり合わせる日々。 最近はイベントストーミングの企画やファシリテートで声をかけてもらうことが多く なってきた。 撮影は @nrslib さん
3. 3 本セッションでお伝えしたいこと • モノタロウは、いかにして ビジネスアジリティを獲得しようとしているか • ビジネスの構造に即した 柔軟なアプリケーションアーキテクチャを構築する • 組織の成長を加速する
4. 4 モノタロウで 基幹システム刷新を行う背景
5. システムと組織 BtoB を対象に、 自ら間接資材の在庫を持ち、 自らオンラインで売るEC企業 コールセンター、商 品 採 用、物 流、 マーケティング、データサイエンス、 IT など多くの業務とシステムを 自社開発、自社運用もしている フルスタック EC カンパニー 事業紹介 5
6. システムと組織 事業紹介 商品点数 2475万点 ユーザー数 約1112万件 売上（連結） 2881億円 グローバルに サービス展開 　※前年比 +13.3% 6
7. わたしたちについて 7 事業成長サイクル 取扱商品 点数拡大 顧客数拡大 在庫点数 拡大 売上・利益 拡大 スケールアップ=利便性アップ •新規顧客獲得増 •ロングテール商品の購入頻度向上 •商品の在庫化が進むことによって 納期短縮、利便性向上 •プライベートブランド化も 推進し利益率向上 •検索ワード数拡大 •ワンストップショッピングの幅拡大 （取扱商品点数2,475万点） •周辺商品の取扱拡大
8. わたしたちについて 8 売上・登録口座数推移 売上は順調に増加 その裏でサービス、機 能、顧客の増加により 業務の複雑性も増加 売上2,000億円 突破 2009.12 東証一部変更 (計画値) （百万円） （千口座）
9. モノタロウのビジネスモデル 事業成長サイクルのも と、商品数、顧客数、注 文数が増加、それにとも なって図の各ネットワー クも拡大していく。 結果、トランザクション 数と複雑性が増す。ドメ インロジックも激増。各 領域毎にスケールできる 状況にしていきたい。 9
10. 我々が提供しているサービスは高度化していく中で、差別化の要因として必要な業務の 複雑性（本質的複雑性）に、長年のビジネス/組織の拡大などによって生じた 不要な複雑性（偶有的複雑性）が付随し、取り組むべき課題に集中できなくなっている。 この不要な複雑性を取り除き、業務とシステムの可変性を再び取り戻すことが必要。 っっｘ 取り組むべ き課題 不必要な複雑性、 煩雑さ 以前 現状 未来 っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ 不必要な複雑性が増え た結果、本来取り組むべ き課題に集中できない 課題を分割すること、不必要な煩雑さ を減らすことで、本来取り組むべき課 題に向き合える状態になる 10 ２つの複雑性
11. 11 • 基幹システムの拡張とビジネスの成長により複雑さが増し、 変更容易性が失われてしまった • 業務の拡張とそれに付随する「複雑性」は モノタロウの差別化ポイントでもある（本質的複雑性） • 継続的な会社の成長のため競争優位の源泉となる複雑性とは何か、 改めて構造的に整理 • その複雑性を基幹システムに落とし込むことで、 業務とソフトウェアの可変性を取り戻し、会社の成長につなげる • 「複雑性を基幹システムに落とし込む」には、モデリングにより 事業要求に根ざしたアーキテクチャとすることが重要 業務とソフトウェアの可変性を取り戻す
12. 12 ドメイン分割と イベントストーミング 　～ドメインモデリング
13. • 仮決めしたドメインにそって組織を再編した（逆コンウェイ戦略） • 既存アプリケーションの各コンポーネントをドメインに割り当てた • ドメインチーム毎にアプリケーションの実行環境分けた 13 ドメイン分割の前にやったこと チームをドメインに従って再編成
14. • 協働的に業務プロセスをモデリングするワークショップの1手法 • 業務側（ドメインエキスパート）とエンジニアが一緒に行う • ワークの結果がソフトウェア設計のインプットになる 14 イベントストーミングとは
15. 1. ドメインイベントを洗い出す 2. 時系列に並べる 3. 分割点となるイベント(ピボタルイベント)をマークする 4. 並行処理を見つける 5. 関係者・外部システムを洗い出す 6. 前から読み上げて曖昧なところがないか検証する 7. グループや集約、ドメイン境界(境界づけられたコンテキスト)を検討する 8. イベントストーミング全体を通じて、業務の認識や言葉の違い・新たな発見がなされる 15 イベントストーミングの進め方 より詳細を知りたい方は、 アマゾンウェブサービスジャパン ソリューションアーキテクトの 福井さんの以下の動画がおすすめ 実践！モノリスからマイクロサービス！ Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo
16. まずは顧客フルフィルメント業務全体を広範囲にイベントストーミング。 エンジニア、業務担当者、マネージャーなど総勢30名ほどが参加して全体感を共有。 ただしこれだけでは、システムの設計からはほど遠い。。。。 Web注文 キャンセル 受注保留 引当て 出荷指示 調達 出荷 配送 実践① 業務全体をイベントストーミング 16
17. 17 受注/配送ドメイン境界議論 実践② 特定の領域でさらに分析 特に受注/配送ドメイン境界が 曖昧だったため議論を深めた。 この議論を通じて、受注ドメインの 責務について論点出しができた。 受注 引当 在庫 出荷 ※これもあくまで１トピックで 他の境界や業務整理が必要なところに ついて随時、分析を加えています
18. 一度に全てを把握することは不可能。 全体から入りつつ、段階的に境界と繋がりを見極めていく必要がある。 抽象度の異なる複数のモデルを往復しながら進めていく手間のかかる作業。 全体から入り、段階的に詳細化し分析する ビッグピクチャー （広範な業務全体のプロセスモデル） コンテキストマップ * （区切られた文脈の関係図） プロセスモデル (特定業務領域の詳細なプロセスモデル) 18
19. 各モデルの棲み分け 19 コンテキストマップ 構造のモデル 流れのモデル ドメイン 全体 ビッグピクチャ 業務領域 プロセスモデル ドメインモデル
20. 各モデルの棲み分け ＋ 観点 20 コンテキストマップ 構造のモデル 流れのモデル ドメイン 全体 ビッグピクチャ 業務領域 プロセスモデル ドメインモデル 業務的 業務的 ほぼ業務的 (詳細化するとアプリ設計に) アプリ的
21. 「流れ」のプロセスモデルから「構造」のドメインモデルを導き出すには ギャップが大きい。プロセスモデルから集約とコマンドを抜き出し、 集約の構成要素(概念)を見極め、概念の関係性を表すモデルを作成した。 実践③ 流れ から 構造 を導き出す リードモデル ・主要な属性 操作 (ドメインロジック) ユースケース (業務イベント) 21 概念構成図はこちらでも ビジネスとアプリケーションを繋げるモデリング - Speaker Deck
22. 22 やってみてわかったこと • イベントストーミングで、複数の関係者が課題認識や前提を作れるのはかなり有効 • 大規模なイベントストーミングは半日から１日程度。ただしそれで終わりではない • 最初はビジネス全体を対象に、その後詳細化して特定の領域で行っていく • 結果、分析はかなり時間と期間を要す。実際に我々は大まかなドメイン境界を決め、 実装のPoC開始まで５ヶ月程度かけている。(専任メンバー＋関係者） • ソフトウェア設計に落とし込むにはイベントストーミングだけではギャップがあり、 他にも様々なワークでモデルを洗練させていく • モデリングのセオリーはあるがそれを全部やる時間はなく、必要に応じて 領域と手法を変えて探索的にモデルを深めていく必要があり、かなり高度な判断となる モデリングを行っての実際
23. 何度も実施することで共通する考え方、質問が身についた • そのドメイン(業務領域)の責務は何か、責務に照らして何をすべきか(すべきでないか) • 集約の境界は適切か、過剰な一貫性を要求していないか • 別々の文脈で登場する同じ名前の概念は、まったく同じ値を指しているか • エンティティや属性、振る舞いの名前は適切か • ある概念の本質は何か、抽象化して拡張性を持たせるべきか • 一回の分析やワークで全てを決めきらない 別の観点でも(モデルでも)整合性を検証しながら、決まっていく 基本的にはユビキタス言語の発見と徹底した利用、境界に細心の注意を払う、カプセル化など イベントストーミングの説明でも触れたものが重要 23 モデリング進め方のポイント
24. 24 新システムの アーキテクチャと 現行システムからの移行
25. ここに「Stock 在庫」があるが、 これは在庫数管理業務ではなく在庫計画などの戦略的な業務 • そもそもモノタロウにおける在庫数管理業務は、受注，配送，発注，倉庫といった 周辺業務の中に溶け込んでおり、ドメインとして確立していない • システム構築当初の「小さいモノリスアプリ」として考えると、 業務に必要な関心事を自ら持つことは一定の合理性があった • 「在庫数管理業務」が複数ドメインの密接な結合点であるため、 難易度は高いがここを最初に整理すると判断 25 在庫ドメインの分析を最初のターゲットにした
26. 26 各種課題を解決するアーキテクチャ PoCアプリケーションが実証したい課題と解決策を要約・抜粋 • 共用DBにある在庫状況は周辺業務の密結合点で、複数の業務の関心事が混在している （業務領域間の結合度を下げる） ◦ 業務領域を基本単位として現行モノリスから切り出し、データも独自に管理する ◦ 他 業務領域とは非同期連携（イベント駆動）とする • 在庫に関する業務知識が散在しており、また共有DBのデータ構造に依存する業務が多い （業務知識とデータ構造をカプセル化する） ◦ 業務領域ごと独自管理するデータに関する操作もひとまとめにする ◦ 業務が扱うデータと、公開するデータのモデルを分ける（CQRS） • 在庫状況TBLは履歴情報を保有できない （変更の履歴を持ち、任意の時点の状態を再現する） ◦ 業務イベント保有し、その積み上げによって最新の状態を得る（Event Sourcing）
27. 27 説明： 既存DBの変更をDMSが検知し てReadReplicaに書き込み、 AWS Lambdaがドメインイベ ントに変換する。 ドメインイベントはMSKに割 り当てられたトピックに登録 され、さらに後続のドメイン ロジックにより処理されて EventStoreに記録され、 ReadModelにも反映される。 移行ステップは部分的に③の状態 新システムのアーキテクチャ概要
28. 28 現行システムからの移行計画 その１ ①EventSourcing＋CQRS環境を構築 ②既存DBの変更をドメインイベントに変換＋新ReadModelDBで業務遂行 ③ドメインアプリが既存DB更新とイベント発行を並行
29. 29 現行システムからの移行計画 その２ ④既存アプリによる既存DB更新と、既存DBの変更検知を廃止 ⑤既存DBへの参照を廃止＋猶予措置として新ReadMoelDBの内容を既存DBに書き戻し
30. 30 新アーキテクチャ移行のつらみ • 現行のモノリスから安全に業務領域を分離するには、責務とインタフェースを 他領域と調整しつつ、分離による影響を最小に抑える工夫が必要 • 「モノリス＆共有DB」と「イベント駆動＆データメッシュ」間の技術的な ギャップを乗り越えるには、アプリケーションのリアーキテクチャリングが必要 （ドメインロジックとそれ以外を整理するチャンス!?） • 「イベント駆動＆データメッシュ」の実現を支援するプラットフォームの 整備・運用が不可欠 • イベントソーシングもCQRSもドメインモデルもオブジェクト指向も 扱えるようになるには教育コストがかかる
31. 31 業務領域間の取り組みを 整合させるには
32. 32 個別の業務領域で検討は進んだ • これまでの営み ◦ 基幹業務全体を俯瞰 ◦ 在庫数管理がフルフィルメントと調達の密結合点か ◦ 在庫数管理を分離、関心事の分離を進める • 在庫数管理・フルフィルメントといった 個別の業務領域でモダナイズを進めることができている
33. 33 改めて各業務領域間の関係を見極める • モダナイズが進む領域でも、 他領域とのインタフェースは想定の域を出ない • 各領域がボトムアップで検討を進めるとともに、 トップダウンでも全体像を描き、領域間の関係を整理する
34. 34 個別領域の検討を加速する • 整理された全体構成の蓋然性を高めるためには、 各領域の内部構造を検討しなければならない ◦ 結果として個別領域の検討を促進することに繋がる ◦ さらに、 「全体俯瞰」「問題領域特定」「改善検討」 「全体の整合確認」「個別領域検討促進」 のように視点を上下して 俯瞰と個別を行き来しながら検討を進められ、 全体と個別の整合を維持することにも繋がる
35. 35 整合を維持し アジリティを生む 現状 未来 っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ さらに未来 エンジニア個々人が内部品質に対する 意識を上げ、組織がコミットする
36. 36 まとめ： これまでの成果と今後の展望
37. • モノタロウが進めるサプライチェーン 高度化の取り組みが進められている • 特にサイトでの在庫表示や配送の サービスレベルアップが進んだ • 現状は商品引き当て、在庫、受注まわり を中心に刷新中 • 今後は、商品、顧客など 他業務ドメインにも展開する 37 これまでの成果と今後の展望
38. 38 【再掲】本セッションでお伝えしたいこと • モノタロウは、いかにして ビジネスアジリティを獲得しようとしているか • ビジネスの構造に即した 柔軟なアプリケーションアーキテクチャを構築する • 組織の成長を加速する
39. 39 まとめ • モノタロウは、サービスを高度化していく中で生じた 偶有的複雑性を取り除くことでビジネスアジリティを 取り戻します ◦ それはドメインモデリングにより業務理解を深め、 認知負荷と予測不能な変更コストの低減で実現します • ビジネスの構造に即した柔軟なアーキテクチャは、 全体と個別モデルの整合を保ち、変更容易性が必要な部分を 見極めてモデリングコストを投じることで実現します • 全体と個別で視点を行き来することで 個別領域のモダナイズを促進する効果も期待できます
40. 40 © 2020 MonotaRO Co., Ltd. All Rights Reserved.