コンテンツにスキップ
SteveTechArcSteveTechArc Courses

矢印の意味を知る

ほかに 19 言語で読めます

English · Español · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)

Data Architectコース第9章、第2部：規模に向けた設計。前へ：クエリと取得のアーキテクチャ。

つながった組織のデータ品質の問題のほとんどは、統合を通じてやってきます。キーが欠けていることによる重複。人知れず止まったバッチによる古い値。書き込むはずのなかったシステムに上書きされた項目。データアーキテクトが統合を作る必要はありません。でもデータアーキテクトは、それがデータに何をしてよいかを決めます。

In a relay race, one runner's hand presses the baton into the next runner's open hand: for an instant, both hold it.

Image generated with AI. ⟲

だからこの章は、いわば試食の盛り合わせです。データアーキテクトのための統合のひと口で、フルコースはIntegration Architectコースにあります。第4章の続きから始まります。システム全体像のどの矢印にも仕組みが必要でした。今度は、どの矢印にも意味が必要です。

この章の考え方

Section titled “この章の考え方 ”
  • Zoom out, then zoom in. Start with the whole landscape, then take one arrow at a time and ask what it means to the data. ⟲
  • **統合アーキテクトが何を計画しているかを知る。**作るのが別の人でも。トラフィックの形がデータの設計を変えます。
  • **誰が会話を始めるかと、データがどちらへ流れるかは別のこと。**そして往復の全体が見えるのはクライアントだけです。
  • Freshness is a requirement, not a default. And a database stores; a process calls: polling needs a process, and polling for nothing is waste. ⟲
  • Singles, sets or bulk: respect the zeros. Integration volume becomes data volume. ⟲
  • One key per record, one-to-one, in an External ID field marked unique. When one customer has several external records, add records, not fields: a hierarchy, peers or a child object (chapter 6), never a key field per system. ⟲
  • A key isn’t authority. Integrations write the fields their system owns, not “the Account.” Two-way movement still has one owner per field. ⟲
  • Proof of delivery: the client owns the conversation; whoever knows what should arrive proves that it did. Log every call, restart gracefully, retry safely, and send increments, not the universe. ⟲
  • **プラットフォームイベントが背骨で、アウトバウンドメッセージはレガシー。**今もサポートされていますが、新しい設計を始める場所ではありません。
  • Every important arrow gets a contract, written before the mechanism is chosen, and it outlives the technology. ⟲

統合のデータ契約

Section titled “統合のデータ契約 ”

Every important arrow gets one, eleven lines: ⟲

LineThe decision
起動側誰が会話を始めるか？
データの方向ビジネスデータはどちらへ動くか？
FreshnessHow current must the data be, in a number?
Volume and shapeHow much, and as singles, sets or bulk?
KeyHow do we identify the same record across systems?
Write authorityWhich system owns, and may write, which fields?
PatternRequest and reply, fire and forget, batch, or events?
仕組み何で実装するか？
Proof of deliveryWho proves it arrived, and owns recovery?
Sensitivity and travelHow sensitive is the data, and where does it pass through?
ChangeHow does the contract change without breaking the other side?

この章の道筋

Section titled “この章の道筋 ”

4つのモジュールがあり、それぞれ単独でも読めます。

  1. Before the Arrow. Steve Trucking’s landscape, then one arrow: who starts it and which way the data moves, how current, polling or listening, singles, sets and bulk, and what happens when it fails. ⟲
  2. Keys and Write Ownership. One key per record, upsert and safe retries, add records not fields, field-level authority, and loops. ⟲
  3. Proof of Delivery. Who proves it arrived, the integration log, restarts and retries, the return receipt, the four shapes and monitoring. ⟲
  4. The Integration Data Contract. Nine contracts on the landscape, one line by line; requirement, then pattern, then mechanism; the standard API or your own; where the data travels; and when the contract says don’t move it. ⟲

Not moving data at all (Salesforce Connect, mashups, zero copy) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon). ⟲

ここでアーキテクトが決めること

Section titled “ここでアーキテクトが決めること ”
  • What each arrow means: initiator, direction, freshness, volume. ⟲
  • **システムをまたいでレコードの対応をどう保つか、**そして誰がどの項目を変えてよいか。
  • **それぞれの移動について、誰が完全性を証明し、**復旧に責任を持つか。
  • そもそもデータを動かすべきかどうか。

**試験の先へ：**エージェントの読み書きの道はどれも統合の矢印です。「顧客を更新する」エージェントには、キー、狭い書き込みの契約、安全な再試行、可観測性が必要です。確率的に動く呼び出し側が、決定的な企業の操作を呼び出しているのですから。各モジュールの最後で、AIが何を変えるかを扱います。

さらに学ぶ

Section titled “さらに学ぶ ”

次へ： 移行と同期