ビジネスとアプリケーションを繋げるモデリング

Slide 1

Slide 1 text

Slide 2

Slide 2 text

尾髙敏之株式会社MonotaRO CTO-Oﬃceグループ在庫モダナイズチームシニアアーキテクト 2 2023年11月にモノタロウ入社。 IT職歴の大半を事業会社のIT部門で過ごし、biz/sysの関係構築や要件定義などの超上流工程に取り組んできたが、「質とスピード」という言葉に出会ってからは品質→保守性に目を開き、モノタロウ入社後は良い構造とは？を求めてチームとすり合わせる日々。最近はイベントストーミングの企画やファシリテートで声をかけてもらうことが多くなってきた。

Slide 3

Slide 3 text

3 早速ですが、、モデリングしてますか？

Slide 4

Slide 4 text

4 どんなときにモデリングしてますか？

Slide 5

Slide 5 text

5 ● 理解を共有したいとき ● 事業や業務を理解したいとき当チームでは

Slide 6

Slide 6 text

6 ● 理解を共有したいとき ● 事業や業務を理解したいとき当チームでは

Slide 7

Slide 7 text

7 理解を共有したいとき

Slide 8

Slide 8 text

8 「モデル≒目的に沿わない詳細を省いた図」と思ってるので、モデルです。たぶん。同じテキストでも、重厚長大なドキュメントより構造化・要約されたテキストのほうがぱっと見で掴めることが多くておすすめです。そのメモの集まりは「モデル」か？

Slide 9

Slide 9 text

9 ● 理解を共有したいとき ● 事業や業務を理解したいとき当チームでは

Slide 10

Slide 10 text

10 ● 事業や業務を理解したいとき ○ ビッグピクチャー ○ コンテキストマップ ○ プロセスモデル ○ ドメインモデル当チームでは

Slide 11

Slide 11 text

11 イベントストーミングで広範囲をざっくりと(ハッピーパスだけ)。画像ではいろいろな付箋を使っていますが、直近では「イベント」と「ホットスポット」だけ使って全体を俯瞰してます。ビッグピクチャー

Slide 12

Slide 12 text

12 DDD的コンテキストマップと異なり、業務領域間の関連を示す図として書きます。 (DDD的...はシステム間の関係性) なので、ビッグピクチャで業務領域が見えたらまず書きます。対象の業務領域が、周辺の業務領域とどう関係するのか線で結んでいきます。ただし、プロセスモデリングまでやらないと十分な情報が揃わないので、進んでは戻りを繰り返します。コンテキストマップ

Slide 13

Slide 13 text

13 いわゆるイベントストーミングを真面目にやります。イベストは真面目にやると大変なので、ビッグピクチャと書きかけのコンテキストマップから「ヤバそうな匂い」がするところに絞って深掘りします。付箋を全色使って、問題領域でどのようなプロセスが営まれているかを可視化します。プロセスモデル

Slide 14

Slide 14 text

14 ドメインモデル図。ざっくりしたクラス図っぽい感じ？アプリケーションの構造みが強いので、ドメインエキスパート（業務の人々）にはちょっと取っつきにくいんじゃないかな？と思ってます。（個人の感想です）ドメインモデル

Slide 15

Slide 15 text

15 ところで流れから構造に変換てプロセスモデル→ドメインモデルへの変換ってギャップを感じないですか？「流れ」を追いかけていたのに急に「構造」を示せって言われても、なかなかしっくりくるものができなくないですかね。（不慣れな業務領域だと特に）

Slide 16

Slide 16 text

16 各モデルの棲み分けコンテキストマップ構造のモデル流れのモデルドメイン全体ビッグピクチャ業務領域プロセスモデルドメインモデル

Slide 17

Slide 17 text

17 各モデルの棲み分け＋なに観点？コンテキストマップ構造のモデル流れのモデルドメイン全体ビッグピクチャ業務領域プロセスモデルドメインモデル業務的業務的ほぼ業務的 (詳細化するとアプリ設計に) わりとアプリ的

Slide 18

Slide 18 text

Slide 19

Slide 19 text

プロセスモデルも詳細化していけば ≒アプリケーション設計にもなるので、つまるところ程度問題でしかありません。モノタロウでは、ドメインモデルでモジュール性を意識した構造化を勧めるので、エンティティ，値オブジェクト，カプセル化，，といった用語が飛び出し、業務担当者を困惑させます 19 ドメインモデルはアプリ寄り？

Slide 20

Slide 20 text

20 そこで「概念構成図」

Slide 21

Slide 21 text

● ドメインモデルよりも業務上の要素とその関係をより精緻に表現できる ● ドメインエキスパートの人にも（比較的）理解してもらいやすい ○ 具体的な業務名(ユースケース)と属性の繋がりを追いやすい ○ 構造化・色分けにより視認性が高い 21 概念構成図？

Slide 22

Slide 22 text

では、早速書き方を 22

Slide 23

Slide 23 text

だがしかし時間が尽きました、、 23

Slide 24

Slide 24 text

24 まずはプロセスモデリングイベントストーミングから知りたいな？という方は、下記をご覧いただくときっと幸せになれます。 ● [E-3] 実践！モノリスからマイクロサービス！Event Stormingによるドメイン駆動設計から実装まで | AWS Dev Day 2023 Tokyo #AWSDevDay ● イベントストーミング入門【ノーカット版】

Slide 25

Slide 25 text

25 コマンド(操作)と集約(概念)とユースケースまず、プロセスモデルからコマンド(青)と集約(黄)を抜き出して配置します。さらに、操作を実行する主体としてユースケースを配置します。ユースケースは、他領域のイベントにより発火したり、アクターにより実行される業務を想定してください。

Slide 26

Slide 26 text

26 概念→属性→リードモデル次に、概念を詳細化して主要な属性を導出します。また、属性の加減算などにより導出可能な属性はリードモデルとして色を分けて配置します。ひとまずこれで「概念構成図」は完成しました。かんたんですね ♪

Slide 27

Slide 27 text

27 まとめ ● メモを配置して線でつないだらモデリング！ ○ 考えがまとまる・伝わる ○ 具体化・抽象化しやすい ● 概念構成図 ○ 「流れ」を「構造」に変換 ○ 非エンジニアとの理解を深める