콘텐츠로 이동

화살표가 무엇을 뜻하는지 아십시오

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: 규모를 위한 아키텍처. 이전: 쿼리와 조회 아키텍처.

연결된 org에서 데이터 품질 문제의 대부분은 통합을 통해 들어옵니다. 키가 없어서 생긴 중복. 조용히 멈춘 배치 때문에 오래된 값. 쓰면 안 되는 시스템이 덮어쓴 필드. 데이터 아키텍트가 통합을 만들 필요는 없습니다. 하지만 통합이 데이터에 무엇을 해도 되는지는 데이터 아키텍트가 정합니다.

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장이 멈춘 곳에서 시작합니다. 랜드스케이프의 모든 화살표에는 메커니즘이 필요합니다. 이제 모든 화살표에는 의미가 필요합니다.

  • 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. ⟲

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?

네 개 모듈, 각각 독립적으로 읽을 수 있습니다.

  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). ⟲

아키텍트가 여기서 결정하는 것

섹션 제목: “아키텍트가 여기서 결정하는 것 ”
  • What each arrow means: initiator, direction, freshness, volume. ⟲
  • 시스템 간에 레코드가 어떻게 짝을 유지하는지, 그리고 누가 어떤 필드를 바꿀 수 있는지.
  • 각 이동마다 누가 완전성을 증명하고 복구를 책임지는지.
  • 데이터가 애초에 움직여야 하는지.

시험 너머: 에이전트의 모든 읽기와 쓰기 경로는 통합 화살표입니다. “고객을 갱신하는” 에이전트에게는 키, 좁은 쓰기 계약, 안전한 재시도, 관측 가능성이 필요합니다. 확률적인 호출자가 결정론적인 기업 작업을 호출하고 있기 때문입니다. 각 모듈은 AI가 바꾸는 것으로 끝납니다.

다음: 마이그레이션과 동기화