背景
疑問
「なぜドメイン駆動などの文脈で語られるイベントストーミングなどは、
プロセス起点で必要なエンティティや属性を出すPOA的アプローチなのに対して、
DOA的なアプローチはあまり語られないのだろうか？」
本来なら、プロセス起点ではなく、ユーザーの欲しい情報を起点にした設計があっても何ら不思議ではないはずでは？」という大きな疑問がずっとああった。
仮説
「カスタマージャーニーマップのように、プロセスモデルを描くようにして、
データになる前の情報をストーリーテリング式に可視化することで、
DOAアプローチや早期からデータ品質を考慮できるはずだ。」と考えました。
前提として、推論というか、ロジックブランチというものをバリバリ使ってます。
こういうメカニズムです。
なぜ「情報を起点」とするアプローチが強力なのか
1. ユーザー価値との直接的な連携
メカニズム
多くの場合、ステークホルダーやユーザーが本当に欲しているのは、特定の「プロセス」が動くことではなく、意思決定や次の行動に必要な 「情報」 です。
例として、「指定した日程で宿泊できる部屋の値段付きで一覧がほしい」は、まさにユーザーが価値を感じる情報そのものです。
この時に、
5W2H式にしてこのストーリーを書いてみると、観点の抜け漏れがなくてより安全です。
効果
この「情報のストーリーテリング」から設計を始めることで、システムが提供すべきビジネス価値の核からブレることがありません。
2. データ品質の先行設計（シフトレフト）
メカニズム
「この情報には、どの程度の品質（正確性、鮮度など）が求められるか？」をビジネスプロセスを設計する前に定義します。
効果
データ品質が、後から対応すべき課題ではなく、システムが満たすべき最優先の非機能要件として位置づけられます。
これにより、その後のビジネスプロセスやコントラクト、そしてマイクロサービスの設計全体が、その品質要求を満たすように強制されます。
3. 疎結合で安定したコントラクトの促進
メカニズム
サービス間の契約を、「Aというプロセスを動かせ」という命令ではなく、「Bという情報を提供せよ」という情報の要求として定義します。
効果
ビジネスプロセス（How）は頻繁に変化しますが、ビジネスに必要な情報の構造（What）は比較的安定しています。
情報を中心に契約を定義することで、より変更に強く、安定したサービス間連携を築くことができます。
ビジネスプロセスのみのモデリングがなぜダメか
ステークホルダーとの議論の時に、確かにプロセス中心の方がドメインの理解をしやすいというのはあります。
ですが、この時に、
プロセスモデリングだけに頼ることは絶対に禁物です。
2つのアプローチの相補的な関係
イベントストーミング（ボトムアップ）：実現プロセス（How）の発見
イベントストーミングは、ユーザーストーリーを満たす実現プロセス（How）の発見です。
イベントストーミングは、「どのように業務が行われるか」というビジネスプロセスを発見し、モデル化するための、たしかに非常に強力なボトムアップの手法です。
このモデリング手法では、プロセスを起点に必要なエンティティデータをボトムアップに抽出しています。
しかし、このアプローチだけだと、
そのプロセスが生み出す「情報」の品質が、
ビジネス上の要求を満たしているかという視点が抜け落ちる
可能性があります。
プロセスが動くこと自体が目的化してしまい、その結果として生まれるデータの品質は、
プロセス品質の延長線上の「副産物」になってしまいかねません。
情報ストーリーテリング（トップダウン）：品質目標（Why/What）の定義
そこで、今回提案するトップダウンのアプローチが必要になります。
まず、ステークホルダーの視点から
「どのような情報を、どのような品質で、いつ必要としているか？」を、
情報ストーリーテリングや抽象度が高めのDFDを用いて明確にします。
これが、アーキテクチャが達成すべき 「ゴール」 となります。
プロセス中心設計と情報中心設計の比較
プロセス中心のアプローチ
イベントストーミングのように、「何が起きるか（イベント）」 を起点に、業務の流れを可視化することに非常に長けています。
情報中心のアプローチ
「何を知る必要があるか（情報）」 を起点に、システムの価値と品質を定義することに長けています。
両者の組み合わせアプローチ
もちろん、情報ストーリーテリングのみでは、
登場すべき情報を全て網羅できない可能性があるため、そこで認知しやすいプロセスからのボトムアップ抽出と組み合わせます。
最も強力なのは、この2つを組み合わせることです。
大まかな手順
①. 情報モデリング
まず、情報中心アプローチで「どのような情報を、どのような品質で提供すべきか」というシステムの「ゴール」と「契約」を定義。
②. ビジネスプロセスモデリング
次にイベントストーミングなどで、その契約を満たすための具体的なビジネスプロセスを発見・設計していく。
この流れは、システムの目的と実装を強力に結びつける、極めて洗練された設計手順です！
理想的な設計フロー
たとえば、宿泊顧客が
【正確で】【最新の】宿泊可能な部屋が【余すことなくすべて】500ms以内に取得できている
というストーリーがあったとしましょう。
非機能要件を**「情報そのものの品質」と「情報を届けるプロセスの品質」**に明確に分離して、情報要件とプロセス要件に。
①. 情報要件の定義（トップダウン）
「情報品質ストーリー」は、データが満たすべき品質特性をユーザーの言葉で表現したものです。これは、情報そのものの内容的・本質的な正しさに関する要件となります。
最新性（Currentness）
【最新の】: これは最新性という品質特性に該当します。
データが最新のものに更新されていることで、誤処理や再処理を行う必要がなくなります。
完全性（Completeness）
【余すことなくすべて】: これは完全性に該当します。
データは目的に応じて抜け漏れなくあることで、詳細な分析をすることができるようになります。
他にも、データの正確性 (Accuracy)（例：「表示されている価格が絶対に間違っていない」）などが、この情報品質に含まれます。
データが真実を正確に反映しているかどうかを評価します。
つまり、データが現実世界の事実に基づいていて、誤った情報や不正確な値が含まれていない状態を指します。
②. ビジネスプロセスの発見（ボトムアップ）
次に、その要求（ゴール）を念頭に置きながら、イベントストーミングを行います。
チームは常に
「今、私たちがモデリングしているこのプロセスは、先ほど定義した品質要求を満たせるか？」
と自問自答します。
「500ms以内に取得」という要件は、まさしくプロセス品質に該当します。
これは、上記で考えた情報をどのように効率的かつ安定的に届けるかに関する要件です。
レイテンシー
「500ms以内に取得できていること」: これはプロセスの性能（パフォーマンス）、
特にレイテンシー（応答時間） という品質特性です。
他の非機能
他にも、プロセスの可用性 （例：「99.9%の時間、システムが利用可能である」）や、
スループット（例：「1秒間に1000件のリクエストを処理できる」）などが、このプロセス品質に含まれます。
③. プロセス品質の導出
この問いかけを通じて、
「【最新の】宿泊可能な部屋(在庫)を保証するためには、宿泊可能な部屋(在庫)更新イベントを500ms以内に処理しなくてはならない」といったように、
情報品質を満たすために必要な、具体的なプロセス品質（SLO） が導き出されます。
なぜこの分離が重要なのか
この情報とプロセス2つを分離して考えることで、問題が発生した際の原因の切り分けと、
責任分界点の明確化が容易になります。(関心の分離)
「ビジネスが要求するデータ品質を達成するために、どのようなプロセスを設計すべきか」という、目的と手段を階層を分けて常に関連付ける ということ。
具体例①
「ユーザーに古い部屋情報を見せてしまった」
→ これは情報品質の問題であり、データソースやキャッシュ更新のロジックに原因がある可能性が高いです。
具体例②
「部屋情報を表示するのに5秒かかった」
→ これはプロセス品質の問題であり、データベースのクエリやインフラの性能に原因がある可能性が高いです。
このように、品質をデータとプロセスの2つの側面で捉えることで、
より精度の高いアーキテクチャ設計と、問題発生時の迅速な原因究明が可能になるのです。
これは、エンタープライズアーキテクチャモデルの階層モデルからインスパイアされています。
