add-integration-event

Publish integration events via outbox and consume them idempotently.

6.7k|2.0k|Updated Aug 20, 2021
One-click install
npx skills add https://github.com/fullstackhero/dotnet-starter-kit --skill add-integration-event
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: add-integration-event
Source: https://github.com/fullstackhero/dotnet-starter-kit/tree/main/.agents/skills/add-integration-event
Command: npx skills add https://github.com/fullstackhero/dotnet-starter-kit --skill add-integration-event

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the problem of coordinating cross-module behavior without tight coupling, ensuring reliable delivery of domain changes across module boundaries.

Core Features & Use Cases

  • Outbox-based event publication: Persist integration events via IOutboxStore inside the source module’s unit of work so delivery is crash-safe.
  • Idempotent, inbox-style handling: Handle events in the consumer module using IIntegrationEventHandler<T> with built-in deduplication keyed by event id and handler name.
  • Tenant-aware consumer processing: Support background-path handling by restoring Finbuckle tenant context when necessary.

Quick Start

Create a {Event}IntegrationEvent in the source module contracts, add it to the outbox within the source handler after your state changes, then implement and register the {Event}IntegrationEventHandler in the consumer module to persist the resulting effects.

Frequently Asked Questions about add-integration-event

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I publish integration events safely within a modular monolith transaction?

Publish integration events safely by adding them to an IOutboxStore within the source module's unit of work transaction. This outbox pattern ensures reliable, crash-safe delivery of domain changes without tight cross-module coupling.

What is the outbox pattern for event-driven architecture in a multitenancy environment?

The outbox pattern persists integration events in the same transaction as domain state changes. For multitenancy environments, consumer processing restores Finbuckle tenant context when handling background-path workflows.

How do I ensure idempotent handlers when consuming integration events across modules?

Ensure idempotent handling by implementing IIntegrationEventHandler<T> in the consumer module. Built-in deduplication keyed by event id and handler name automatically prevents duplicate processing of cross-module integration events.

How do I register integration event handlers in a vertical-slice modular monolith?

Register consumer handlers by calling AddIntegrationEventHandlers for your IIntegrationEventHandler<T> implementations. This wires up idempotent, inbox-style event processing for vertical-slice modular monolith cross-module reactions.

Do I need a stable IIntegrationEvent type in source contracts for event-driven architecture?

Yes, a stable IIntegrationEvent type in source contracts is required. Defining a {Event}IntegrationEvent allows the source module to publish outbox-backed domain changes and consumer modules to react reliably.

Can I use the outbox pattern for tenant-scoped background workflows in a modular monolith?

Yes, the outbox pattern supports tenant-aware consumer processing for background workflows. It restores Finbuckle tenant context during handling, enabling reliable domain change reactions across module boundaries.