そのデータ連携、ホントにそれでいいの？ 〜データモデル分析の重要性を説く〜 / How to analyse data integration - Speaker Deck
めちゃめちゃ参考になるなこれ。
イベントは2024年8月だったとのことだが記憶にない。見逃していたようだ。
というわけで自分で整理して理解を深める。
ドメイン分析の4軸
スライドでは「データ連携は4つに分解して考える」とあるが、これから行うアーキテクチャ検討に向けて転用を考えるために敢えてドメイン分析と題しておく。
イベント分析
所有分析
データフロー分析
システムコンテキスト分析
イベント分析
対象データはどのような変更理由を持つか
所有分析
機能的凝集度を踏まえ、そのデータを誰が所有すべきか
データフロー分析
データの品質特性を踏まえて、データフロー図を描く
システムコンテキスト分析
これまでの分析結果と、ビジネス観点、チーム体制等を踏まえてアーキテクチャ構成とデータ連携を整合させる
イベント分析
「注文」というデータ≒集約が持つ変更契機は何か。
集約が持つべき振る舞いを特定するのはもちろん、集約のスコープも最適化したい。
例えば
当初、「注文」という集約には「注文依頼」「注文キャンセル」「配達開始」「配達完了」というイベントを持っていた。
https://scrapbox.io/files/6714bf1d311564e42b36d1c8.png
ドメインエキスパートとの対話により、
注文としてのスコープは出荷指示までであり、出荷指示後の配送状況は別の関心事であることが分かったので、
集約を「注文」「配達状況」に分けることとした。
https://scrapbox.io/files/6714bf3c479586aee749fafc.png
所有分析
基本的にデータ（≒集約）の所有者は、その集約を変更する単一の業務領域である。
複数の業務領域が関連する場合は、その集約に対する用途と制約を整理することで所有すべき業務領域（≒責務
を明らかにできる。
例えば
とある管理画面の機能で、SMSによる配信設定に「通数上限」を設定できたとする。
現状では「管理画面サービス」がフロントエンドからのリクエストに応じて更新している
（通信上限を所有している）
https://scrapbox.io/files/6714c1d0737c3adc67b8a53f.png
用途と制約（と前提）を整理すると下記のようになった。
前提：「送信依頼」「送信完了」という状態はSMS送信サービスが所有している
用途：新たにSMSを送信する際、既にある「送信依頼」「送信完了」と比較し、月間で「通数上限」を上回らないよう制御したい。なぜならば、SMSの送信は従量課金であり予算制約があるからだ
制約：「通数上限」＜「送信依頼」＋「送信完了」を満たす必要がある
https://scrapbox.io/files/6714c1e61b61a530e6bd4a94.png
以上のことから、通数上限は管理画面サービスではなく、SMS疎巣品サービスが所有したほうが連携パスを無くすことができ有利と判断できる
データフロー分析
データをどのように流通させるか。
データフロー図の作成（データごとに適した連携手段を考察）
データフロー俯瞰図を作成（個々の連携を一つの図にまとめる）
データごとと言うが、集約だけではなくコマンドやイベントも含むすべての通信経路を指しそう。
手段は大きく分けて3つ
APIによる同期型通信。リクエスト・レスポンス
RDS as Readonly-Data Store。リードモデルの開示（複数のデータストアをETLして作成するのかも）
イベントストリーミング：キューやPub/Subによる非同期通信。
例えば（連携手段を考える←何を伝えるか）
業務イベントまたはコマンド
バックエンドによる処理の状態(受付 / 完了 / 中止 など)をConsumerに通知するには、特別な制約がなければ非同期でいいだろう
集約の状態
バックエンドによる処理の結果（含：データセット）をConsumerに通知するにはRDSによるクレームチェックパターンが適すだろう（非同期通知→Consumerがリードモデル参照）
強い整合が必要な情報
結果整合ではなく最新の状態を必要とする業務であればAPIによる同期型通信が必要だろう
が、ともすると思考停止で強整合となりがちなので、流通経路によるpros/consを念頭に判断したい
データごとに連携手段を設定出来たらひとつの図にまとめてみる
as コンテキストマップ？
よりも細かいものになるかも。
コンテキストマップ→業務領域単位で、その「関係」を描く
本図→データ連携ごとにその手段を描く
コンテキスト分析
ビジネスの関心事 ／ データフロー俯瞰図 ／ チーム体制 をインプットにシステムコンテキストを分析する。
ここで書くのがコンテキストマップだな
現状のガイドラインでは下記としているが、本手順と比べてデータフロー分析が疎かかも。
（だから今、同期 / 非同期でわちゃわちゃしているのかも）
ビッグピクチャ描く
とりまコンテキストマップ描け
プロセス分析しろ
コンテキストマップも精緻化しろ
所有分析とデータフロー分析しろ ← new
コンテキストマップも精緻化しろ
プロセス分析後だと細かすぎるか？
でもビッグピクチャレベルだとあまりにも雑になりそうだが。。
とりあえず基幹アーキMTGでやってみるか
さらに
C4モデルも作ったそうだ
Context > Container > Component > Code で C4。
https://scrapbox.io/files/6714ca3902dfae385acf1546.png
物理構成はいいかな。
全体の整理としては、この上位にある「事業 > 業務領域 > 業務機能」という構成と、システム機能を紐づけるところまでだろう。（いわゆるシステムコンテキスト図までか）
https://scrapbox.io/files/6714cad7f595192e86d5ed49.png