BitzOrcas addresses cross-cutting concerns through building blocks and middleware that every module benefits from automatically. Unlike frameworks that require per-module opt-in, BitzOrcas’s Mediator pipeline and middleware chain provide most cross-cutting behavior as transparent infrastructure.
Available cross-cutting features
| Feature | Implementation | Status |
|---|---|---|
| Error handling | GlobalExceptionHandler + Result<T> | ✅ Implemented |
| Rate limiting | ASP.NET Core RateLimiter (3 policies) | ✅ Implemented |
| Idempotency | IdempotencyPipelineBehavior | ✅ Implemented |
| Observability | OpenTelemetry + OTLP | ✅ Implemented |
| Health checks | Aspire ServiceDefaults | ✅ Implemented |
| Audit pipeline | Channel queue + async writer | ✅ Implemented |
| Background jobs | Quartz.NET JobHost | ✅ Implemented |
| Caching | IMemoryCache | ✅ Implemented |
| Feature flags | IFeatureStore (null default) | 📋 Planned |
| HTTP resilience | Polly/Retry | 📋 Planned |
| Realtime | IChatRealtimeAdapter | 📋 Planned |
Mediator pipeline — the cross-cutting backbone
Most cross-cutting concerns are applied through the Mediator pipeline, ensuring every request automatically benefits:
Request → Logging → Authorization → Validation → Idempotency → Transaction → ActivityAudit → HandlerNo per-endpoint configuration needed — pipeline behaviors are registered once and apply globally.
Middleware chain — request-level concerns
Request-level cross-cutting behavior is handled by the middleware pipeline in Program.cs:
ExceptionHandler → CorrelationId → Authentication → DelegationToken→ TenantResolution → RequestAudit → Authorization → RateLimiter → EndpointsDesign philosophy
- Convention over configuration: Most cross-cutting features work out-of-the-box
- Null defaults: Every port has a null/default implementation — no infrastructure needed to start
- AOT-compatible: API Host stays trim-safe; heavy dependencies (Quartz, SignalR) run in separate hosts
- Configurable: Features can be toggled or configured via
appsettings.json