Skip to content
  • product-portfolio
  • ecosystem-catalog
  • deep-dives
  • core

APIs, Integrations, Connectors & Developer Ecosystem - Analysis

Planning-layer analysis for category 8. It groups the 50 candidate services into capabilities, recommends what becomes a standalone service versus a module, and captures domain, interface, and non-functional notes. For the plain item list see the browse page.

Scope & Bounded Context

  • Primary bounded context: API & Integration
  • Group: core
  • Default wave / cycle: Phase 2 · Cycle 1: AI Factory SaaS
  • Items: 50 candidates

This category is anchored to the ConnectSoft DDD baseline in the SaaS framework DDD blueprint and the service classification model.

Classification Breakdown

Classification Count
Connector 4
Microservice 8
Module-in-service 25
Portal/UI Module 6
Shared Library 7

Anti-fragmentation stance

Per ADR-0011, the 25 module candidates below are delivered inside the API & Integration bounded-context service, not as separate microservices. Only the 8 platform/service candidates justify an independent runtime.

Standalone Service / Platform Candidates

ID Service Tier Status
CS-SVC-0351 API Gateway 1 Planned
CS-SVC-0352 BFF Gateway 1 Planned
CS-SVC-0353 YARP Gateway Template 1 Planned
CS-SVC-0355 GraphQL Gateway 1 Planned
CS-SVC-0356 gRPC Gateway 1 Planned
CS-SVC-0357 WebSocket Gateway 1 Planned
CS-SVC-0384 Webhook Inbound Gateway 1 Planned
CS-SVC-0399 Partner API Gateway 1 Planned

Connector Candidates

  • Connector Registry (CS-SVC-0378) - plugin in the Connector Runtime.
  • Connector Runtime (CS-SVC-0379) - plugin in the Connector Runtime.
  • ETL Connector Service (CS-SVC-0383) - plugin in the Connector Runtime.
  • Connector Credential Vault (CS-SVC-0394) - plugin in the Connector Runtime.

Portal / UI Modules

  • API Catalog Portal (CS-SVC-0358)
  • Developer Portal (CS-SVC-0359)
  • API Key Portal (CS-SVC-0360)
  • API Subscription Portal (CS-SVC-0361)
  • API Usage Dashboard (CS-SVC-0366)
  • Integration Health Dashboard (CS-SVC-0393)

Domain, Interfaces & Data Ownership

  • Aggregates are owned by the API & Integration context; cross-context reads go through published contracts, never shared databases.
  • Integration is event-first (outbox + integration events) per the event-driven mindset.
  • APIs are contract-first and versioned through the API & Integration context.

Non-Functional Posture

  • Multi-tenancy & edition-awareness: required for all serious candidates.
  • Security: Standard baseline; secrets via the platform secret store; least privilege.
  • Compliance: standard audit logging.
  • Observability: OpenTelemetry traces, metrics, and structured logs.

MVP vs Future

  • MVP (Tier 0-1): API Gateway, BFF Gateway, YARP Gateway Template, Azure API Management Integration, GraphQL Gateway, gRPC Gateway, WebSocket Gateway, API Catalog Portal
  • Future (Tier 4-5): none

Open Questions

  • Which module candidates, if any, develop independent scaling or ownership needs that would justify promotion to a standalone service?
  • Where do this category's contracts overlap with adjacent contexts, and who owns them?