Asset Management Events and Integration Contracts
Summary
Complete Draft documentation for the source-backed Asset Management event model: six domain events raised by the Asset aggregate, mapped 1:1 to six shared integration contracts, staged in the transactional outbox on save, and drained by a registered hosted relay through the shared event bus. It also documents the single confirmed consumer (Notification), the HTTP-only workflow and document boundaries, identifier-only employee references, compatibility identity carried in the payload, and verified reliability behavior.
Audience
Backend engineers, integration engineers, QA, support, architecture, security reviewers, product owners, and implementation partners responsible for Asset Management eventing.
Overview
The Asset aggregate raises six typed domain events (AssetRequested, AssetAssigned, AssetReturned, AssetRejected, AssetLostOrDamaged, AssetRetired), each carrying a uniform AssetLifecycleData snapshot. On SaveChangesAsync, AssetDbContext translates each raised domain event into the matching HrSuit.Contracts integration contract, runs a payload-completeness guard, serializes it, and stages it as an outbox row inside the same local transaction as the aggregate change.
A registered background relay (OutboxRelayHostedService) polls the outbox and hands pending and failed rows to the shared OutboxProcessor, which publishes through the shared RabbitMqEventBus. Successful publishes are marked processed; failures increment a retry count and remain eligible for the next pass. Broker delivery therefore depends on broker availability and configuration, which this documentation task does not verify (no messaging infrastructure was contacted).
Notification is the only confirmed consumer service: it recognizes all six asset event names, projects the uniform payload, and maps each to an Asset.* notification template. Workflow and document interactions are HTTP request/response boundaries, not events. Employee/user references travel as numeric identifiers in the payload; there is no employee event consumption in asset-service.
The event model is classified Transitional because the outbound path is complete while the inbound consumer path in asset-service is Foundation (a ProcessedIntegrationEvent ledger exists but no subscription is wired), and because broker delivery, retry ceilings, cleanup, and reconciliation require confirmation.
Documentation map
- Event Overview, Event Architecture, Domain Events, and Integration Contracts
- Lifecycle-to-Contract Mapping, Publishing and Outbox, Producer Behavior, and Consumer Landscape
- Notification Consumer, Workflow Boundaries, Employee Boundaries, Gateway Boundaries, and Document Boundaries
- Compatibility Events and the lifecycle families: Assignment Events, Request Events, and Lifecycle Events
- Contract Versioning, Idempotency, Ordering and Correlation, and Retry and Failure
- Event Testing, Verified Event Catalog, Event Limitations, and Source Map
Requires confirmation
Broker delivery in each environment, retry ceilings, dead-letter policy, outbox and processed-event cleanup, reconciliation, contract governance, notification template ownership, and inbound-consumer activation require confirmation.
Source References
microservices/src/asset-service/Domain/Asset/AssetDomainEvents.csmicroservices/src/contracts/Events/AssetLifecycleEvents.csmicroservices/src/asset-service/Infrastructure/AssetDbContext.csmicroservices/src/asset-service/Messaging/OutboxRelayHostedService.csmicroservices/src/notification-service/Application/EventNotificationResolver.cs
Related Articles
See Also
Keywords
- Asset events
- Integration contracts
- Transactional outbox
Revision Information
- Status: Draft
- Last reviewed: 2026-07-17
- Review cycle: Quarterly