20240522 Findy Event ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する.pdf
•
0 likes•23 views
モノタロウ、Findyイベント登壇資料 イベントストーミング、モデリング
More Related Content
Similar to 20240522 Findy Event ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する.pdf
Similar to 20240522 Findy Event ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する.pdf (20)
More from 株式会社MonotaRO Tech Team
More from 株式会社MonotaRO Tech Team (20)
Recently uploaded
Recently uploaded (8)
20240522 Findy Event ビジネスの構造をアーキテクチャに落とし込みソフトウェアに可変性を注入する.pdf
- 1. ビジネスの構造をアーキテクチャに落と し込みソフトウェアに可変性を注入する 2024/5/22 株式会社MonotaRO CTO 普川泰如 1 © 2022 MonotaRO Co., Ltd. All Rights Reserved. モノタロウ基幹システム刷新の実践例
- 2. ● イベントストーミングは、特に業務側メンバー（ドメインエキスパー ト）と問題空間を共有するのにとても有効 ● ただし実際にモデルを洗練させるためには抽象度を変えて段階的に関心 の分離を行う ● 他の手法も使いながらモデリングを洗練させていく ● モデリングした分析結果から、業務の変更パターンを見える化しそれを アーキテクチャに落とし込むことで、ソフトウェア・業務に可変性を持 たせることができる（はず） 2 今日の話の要約
- 4. システムと組織 4 BtoB を対象に、 自ら間接資材の在庫を持ち、 自らオンラインで売るEC企業 コールセンター、商 品 採 用、物 流、 マーケティング、データサイエンス、 IT など多くの業務とシステムを 自社開発、自社運用もしている フルスタック EC カンパニー 事業紹介
- 10. 10 課題と取り組み内容まとめ ● 基幹システムがモノリスアプリケーションであり、拡張とビジネス成 長によって複雑さが増し、変更容易性が失われた。 ● 一方で業務のスケールとそれに付随する「複雑性」はモノタロウの差 別化ポイントでもある ● 継続的な会社の成長のため競争優位の源泉となる複雑性を改めて構造 的に理解をする。 ● その複雑性をアーキテクチャの構造に落とし込むことで、業務とソフ トウェアの可変性を担保し、会社の成長につなげていくことを行う ● アーキテクチャ設計が事業要求に根ざしたものにすることが重要
- 12. ● 協働的にドメインのモデリングを行うワークショップの1手法 ● ドメインエキスパート(業務側)とエンジニア(システム側)が一緒に行う ● ワークの結果がソフトウェア設計のインプットになる 12 イベントストーミングとは
- 13. 1. ドメインイベントを洗い出す 2. 時系列に並べる 3. 分割点となるイベント(ピボタルイベント)をマークする 4. 並行処理を見つける 5. 関係者・外部システムを洗い出す 6. 前から読み上げて曖昧なところがないか検証する 7. グループや集約、ドメイン境界(境界づけられたコンテキスト)を検討する 8. イベントストーミング全体を通じて、業務の認識や言葉の違い・新たな発見がなされる 13 イベントストーミングの進め方 より詳細が知りたい方はAWSのSA福井さんの以下の動画がおすすめ 実践！モノリスからマイクロサービス！ Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo
- 14. ● ステークホルダー全員の共通認識のもと分析されたビジネスプロセスが可視化される ○ ドメイン・集約 = 関心事の凝集 ○ 境界づけられたコンテキスト = 関心事の分離 ○ ユビキタス言語 = 言葉の統一による共通認識の深化 ● ドメインモデルが、システム設計のインプットになる ○ ドメインモデル = (レイヤード|ヘキサゴナル|オニオン)アーキテクチャにおけるド メイン層の実装そのもの ● 得られるメリット ○ 業務側・システム側の共通理解がそのままシステムに反映される ○ 関心事が分離されているので、各システムが独立して変化できる 14 まとめると
- 15. ● 仮決めしたドメインにそって組織を再編した。（逆コンウェイ戦略） ● 既存アプリケーションをコンポーネント毎にオーナードメインを決めた ● ドメインチーム毎にアプリケーションの実行環境分けた 15 ドメインモデリングの前にやったこと
- 19. やってみてわかったこと ● イベントストーミングでは、複数の関係者が課題認識や前提を作るのはかなり有効 ● 1回のイベントストーミングは半日から１日程度。ただしそれで終わりではない ● 最初は業務全体を対象に、その後詳細度を上げて特定の領域で行っていく ● 結果、分析自体はかなり時間と期間がかかる。実際に我々は大まかなドメイン境界を決め、 実装のPoC開始まで５ヶ月程度かけている。(専任メンバー＋関係者） ● ソフトウェア設計に落とし込むにはイベントストーミングだけではギャップがあり、他にも 様々なワークでモデルを洗練させていく（後述） ● モデリングのセオリーはあるがそれを全部やる時間はなく、必要に応じて領域と手法を変え て探索的にモデルを深めていく必要があり、かなり高度な判断となる 19 ドメインモデリングを行っての実際
- 20. 何度も実施することで共通する考え方、質問が身についた ● そのドメイン・エンティティの責務は何か ● 集約が大きすぎないか、分けられる点はないか ● 別々のコンテキストで登場する同じ名前のものがまったく同じ値を指しているか ● エンティティや属性、振る舞いの名前が適切か ● 一回の分析やワークで全てを決めきらない。その後の別の観点での整合性を検証しなが ら、決まっていく 基本的に関心事の凝集・分離・ユビキタス言語の発見など、イベントストーミングで説明され ている基本が重要 20 ドメインモデリング進め方のポイント
- 22. ここに「Stock 在庫」があるが、 これは在庫数管理業務ではなく在庫計画などの戦略的な業務 ● そもそもモノタロウにおける在庫数管理業務は、受注，配送，発注，倉庫といった 周辺業務の中に溶け込んでおり、ドメインとして確立していない ● システム構築当初の「小さいモノリスアプリ」として考えると、 業務に必要な関心事を自ら持つことは一定の合理性があった ● 「在庫」が複数のドメインとの密接な結合点であるため、難易度は高いがここを最 初に整理すると判断 22 在庫ドメインの分析を最初のターゲットにした
- 23. ● ビジネスの成長とともにシステムも徐々に大きくなっていき変更を加えた結 果、在庫状況TBLは神テーブルとなり周辺業務の密結合点となり果ててしまっ た。特に以下３つの課題がクリティカルであった ● 課題１：在庫数管理とは本来無関係な周辺業務の属性をTBLに多数追加された （受発注／入出荷保留数など） →属性の本来の責務のドメインの特定 ● 課題２：システムの成長によりテーブルへのカラム追加が難しくなった。結 果、在庫管理がもつべき属性を別のテーブルやアプリケーションのロジックで もつこととなった（出庫余力など） →参照レイヤーを更新と分離させる ● 課題３：テーブルの更新がUPdateでおこなわれるため履歴情報が一箇所に残っ ていない→履歴を残す必要がある 神テーブルの爆誕と顕在化した課題 23
- 24. ● 在庫管理システムのメインの責務は商品の入庫と出庫の数と理由の管理。その在庫の状態 の変更イベントの変更は少ない（ただし集約の必要はある）一方在庫ドメインで取り扱う 属性数が多く、また継続的に追加される 24 在庫業務の構造１ 取り扱う属性数が多い 発注ドメイン 在庫ドメイン 配送ドメイン 発注 入荷 引当 出荷 ここの変更、追加要求 が多い 商品が入る
- 27. ● 仮想コードで在庫ドメインの実装や命名のイメージを固める ● 関係者総出でモブプロを見守り認識合わせ ● シーケンス図で周辺ドメインとのメッセージングを検証 ● さらにドメインモデルを洗練させる 27 ドメインモデルを洗練させる
- 28. 28 ドメインモデルを洗練させるためにやったこと ● ドメインモデルを洗練させるとは「深いドメイン知識」をモデルに反映していくこと ● そのためには色々な観点でモデルを解釈、整合がされるようにマッピングさせること が重要 観点 ワークショップ例 既存 AS-IS 業務 ● 業務プロセス分析 ● シーケンス分析 ソフトウェア ● 既存データモデリング分析 ● 既存コンポーネント分析 新 To-Be 業務 ● バリューストリームマッピング ● ドメインビジョン定義 ソフトウェア ● プロトタイピング ● システムアーキテクチャ
- 29. ● イベントストーミング ○ 問題空間の概要をシステム側業務側全員で把握できる。ユビキタス言語の獲得 ● データモデルの分析 ○ 既存のデータモデルから集約を抽出し整理をする。既存システムとのマッピングが しやすい ● シーケンス分析 ○ 色々な業務のユースケースを考慮してみることでモデリングが洗練される ● 仮想コード ○ コードに落とし込むことで実装観点での矛盾、開発者のドメイン知識獲得も行える 29 モデリングで我々がよく行ったワーク
- 32. ● 業務側メンバーとの体制構築や知見をモデリングに反映の仕方 ● ドメインオーナーの獲得（ドメインビジョン、あるべき姿Tobeをどうモデルに反映 させるか） ● モデリング結果を既存システムに段階的に適用の仕方、移行方法 ● アーキテクチャ、ソースコードレベルでのモデリング適用例 32 今日の話で触れなかったこと
- 33. ● イベントストーミングは、特に業務側メンバー（ドメインエキスパー ト）と問題空間を共有するのにとても有効 ● ただし実際にモデルを洗練させるためには抽象度を変えて段階的に関心 の分離を行う ● 他の手法も使いながらモデリングを洗練させていく ● モデリングした分析結果から、業務の変更パターンを見える化しそれを アーキテクチャに落とし込むことで、ソフトウェア・業務に可変性を持 たせることができる（はず） 33 まとめ（再掲）