背景
アーキテクチャを考える際には、プロセスの側面のみを考えてはいけないです。
しかしながら、アプリケーションしか担当しない人などはしばしば、アプリケーション内でのトレードオフは考えても、その領域にない、データへの影響などを間上げない人もたまにいます。
そこで今回、プロセスもデータも互いに影響し合うが、それらを同時に考えることは複雑。
ですが、どちらも設計思想は共通点があるために、そのメカニズムについて触れたいと思います。
影響された本やフレームワーク
影響を受けた本
最も影響されたのは以下の本です。
こちらの本では、プロセスと情報を明確に関心を分けて考え、後から融合させるスタイルを取っています。
すこし違うものにはなりますが、エンタープライズアーキテクチャモデルの４層でも、
データ（情報）とプロセスに相当するアプリケーションの層は分離して考えています。
影響を受けたフレームワーク
私が過去によく使っていたアーキテクチャフレームワークも、情報とプロセスを明確に分離していました。
グレー列のInformationで、分析系の情報や、トランザクション系の情報を扱うという感じです。
メカニズムは一緒
プロセスでも、データでも、まずは
論理的な世界観での境界などを考察した論理アーキテクチャ
を考察後に、いろいろな品質や予算・マネジメント負荷などの
制約を踏まえて物理的な境界を定義し、物理アーキテクチャに落とし込む
メカニズムは一緒です。
プロセスとデータで共通しているのは、それが
「何を達成したいか（What）」
「どうやって実現するか（How）」
とを分離するという、問題解決における普遍的な原則に基づいているからです。
なぜこのメカニズムは普遍的なのか
この「論理→物理」という思考プロセスは、複雑な問題を扱うための、非常に強力なフレームワークです。
複雑系のビジネスになればなるほど、その威力はさらに増し、変化に強いビジネスのためには、物理アーキテクチャと論理アーキテクチャは、明確に分けてトレーサビリティを保つのが、私はマストだと思っています。
1. 関心の分離
論理アーキテクチャは、ビジネスの要求やドメインのルールといった「関心事」に焦点を当てます。ここでは、技術的な制約は一旦脇に置き、理想的な構造を追求します。
物理アーキテクチャは、パフォーマンス、コスト、セキュリティ、耐障害性といった
「非機能要件」という別の関心事に焦点を当てます。
これらを同時に考えると、ビジネスロジックとインフラの問題が混ざり合い、思考が混乱してしやすくなります。
非機能の内容のみが変わった際にも、ビジネス要素のみの論理が残っていれば、
保守も行いやすいです。
そこで、関心を分離することで、それぞれの問題に集中できます。
2. 複雑性の管理
最初に論理的な世界観を構築することで、システムの全体像と本質的な構造を、実装の詳細に惑わされずに理解できます。
複雑な問題に取り組む際に、まず抽象的なモデルから始めるのは、人間の認知的な限界に対応するための定石です。
3. 選択肢の維持
一つの論理アーキテクチャに対して、複数の物理アーキテクチャの選択肢があり得ます。
例えば、「論理的に分離されたサービス」は、「物理的に別のマイクロサービス」として実装することも、「モノリス内の別モジュール」として実装することも可能です。
これは、私が先日の登壇で、
「１つのサービス内になぜ複数の集約を含むのか？」
というテーマで発表しています。
最初に論理設計を固めることで、後から技術の進化や予算の都合に合わせて、最適な物理実装を選択する柔軟性が生まれます。
プロセスとデータの類似性
この原則は、システムの振る舞い（プロセス）と、システムが扱う情報（データ）の両方に全く同じように適用できます。
データとプロセスの相互作用
この図は非常にわかりやすいアナロジーだと思います。
目的と手段の関係
データの品質特性が目的としたら、アプリケーション品質（非機能）は手段。
データ品質は、必ずアプリケーション品質というものの制約を受ける構図です。
むやみやたらに、アプリケーション品質を改善するのではなく、
そのアプリケーション品質の改善によって、
どんなデータ品質改善が行われ
代償として、どのような副作用があるのか？
を必ず事前に考えなくてはいけません。
ロジックブランチで可視化する
アブダクションでアプリ品質を特定
もしも先に明確に
「こんなデータ品質が満たされていてほしい」
という要求があれば、そこからアブダクションすることで、アプリケーション品質が決定されます。
よくある、先にアプリケーションアーキテクチャを決定する場合には、
そこから演繹的に、どのようなデータ品質を満たせるのか？を考えます。
まとめ
結局のところ、プロセスもデータも、ビジネスという目的を達成するための手段です。そのため、その設計プロセスが「目的（論理）→手段（物理）」という同じ構造を辿るのは、非常に自然なことです。