Skip to content

Native SDK With Shared Transport

When To Use

Use this archetype when the vendor provides a native library, process, or SDK that must be initialized once and shared across multiple devices or sessions.

Core Shape

  • adapter-wide transport or shared provider owns SDK lifecycle
  • protocol objects encapsulate per-device operations
  • message or callback pump converts SDK activity into adapter events
  • command handlers call protocol methods, not SDK primitives directly
  • optional access synchronization and mapping artifacts

Typical Files

  • Communication/Transport.cs
  • Communication/Protocol.cs
  • Communication/<Initialization>.cs
  • Events/*.cs
  • Commands/*.cs
  • Capabilities/AccessSynchronization.cs

Minimal Flow

SDK callback/message pump -> transport -> protocol/event router -> Thing method -> PQ event

command -> protocol -> SDK operation -> command result

Common Pitfalls

  • leaking SDK details throughout the adapter instead of isolating them in transport/protocol
  • skipping serialized access when the SDK is not thread-safe
  • keeping long-lived Thing references in shared services
  • mixing event translation and raw SDK parsing in the same large method

Good First Deliverable

Build the SDK lifecycle wrapper, parse one callback or event type, and implement one command through the protocol boundary.