Seven platform modules are implemented today, each a bounded context with its own ports, adapters, and contracts assembly. Business modules (Cases, Billing, Workflow) are planned for future phases.
- 01/10
Identity module
Platform identity system — RBAC permission model with roles, modules, permissions, role-types, platform tenants, and CSV-based seed data management.
- 02/10
Multitenancy module
Multi-tenancy system — 8-level ITenantResolver chain, TenantStatusGuard, PlatformTenantEntity, tenant lifecycle management, and cross-tenant query patterns.
- 03/10
Auditing module
Comprehensive audit system — 7-category sharded storage, channel-based async pipeline, entity change tracking, retention policies, and Quartz-based cleanup jobs.
- 04/10
Files module
File management module — FileAssetService for upload/download/delete with tenant isolation, LocalFileStorage integration, and cross-module attachment support.
- 05/10
Chat module
Multi-channel messaging — ChatService with channels, members, messages, mentions, read markers, file attachments, and a pluggable realtime adapter interface.
- 06/10
Notifications module
Multi-channel notification system — in-app inbox with preference management, template-based notifications, delivery adapter ports, and CAP event publishing.
- 07/10
Webhooks module
Full-featured webhook system — subscription management, HMAC-SHA256 request signing, exponential backoff retries, dead letter queue, IP allowlist, and per-subscriber rate limiting.
- 08/10
Billing module
Platform billing — subscription management, plan catalog, usage recording, quota enforcement, invoice generation, and entitlement resolution.
- 09/10
Catalog module
Product/service catalog — plan definitions, add-on offerings, entitlement mappings, and configurable catalog items for SaaS subscription management.
- 10/10
Tickets module
Support ticket system — lifecycle management with state transitions, agent assignment, comments with file attachments, role-based authorization, and audit trail.
Implemented modules
| Module | Purpose | Contracts | Key ports |
|---|---|---|---|
| Files | File asset management, presigned upload URLs, owner policies | FileAsset, FileAssetSummary, FileAssetState | IFileAssetRepository, IFileStorage |
| Notifications | In-app notification inbox with severity and state tracking | Notification, NotificationSummary, NotificationState | INotificationRepository, INotificationPublisher |
| Webhooks | External event subscriptions, HMAC signing, delivery logs, retries | WebhookSubscription, WebhookDeliveryLog, WebhookSignature | IWebhookSubscriptionRepository, IWebhookDeadLetterQueue |
| PlatformBilling | SaaS plans, subscriptions, entitlements, usage metering, invoicing | Plan, PlatformSubscription, UsageRecord, PlatformInvoice | IPlatformBillingRepository |
| Catalog | Product catalog with categories, pricing, and plan mappings | CatalogItem, CatalogItemSummary, PriceModel, Category | ICatalogRepository |
| Tickets | Support tickets with lifecycle, comments, attachments, and status machine | Ticket, TicketStatus, TicketTransitionRules | ITicketRepository, ITicketAttachmentAccessService |
| Chat | Channels, messages, memberships, read markers, mentions, realtime | ChatMessage, Channel, ChannelMembership, ReadMarker | IChatRepository, IChatRealtimeAdapter |
Planned modules (future phases)
| Module | Purpose |
|---|---|
| Identity | User accounts, MFA, external identity federation |
| Cases | Legal case management — the core business domain |
| Billing | Financial billing, invoice management, revenue protection |
| Workflow | Custom workflow engine core — definition, instance, tasks, gateways, SLA |
The module five-piece suite
Every module follows the same structure per ADR 0017:
src/Modules/<Category>/<Module>/ BitzOrcas.<Module>.Contracts/ # Public contracts (DTOs, Integration Events, Constants) BitzOrcas.<Module>.Domain/ # Domain model (entities, value objects, domain events) BitzOrcas.<Module>.Application/ # Use cases (Commands, Queries, Handlers, Pipelines) BitzOrcas.<Module>.Infrastructure/ # Persistence / external integration BitzOrcas.<Module>.Endpoints/ # Minimal API endpoints + AddModule extensionDependency direction is strictly unidirectional: Endpoints → Application → Domain. Cross-module communication goes through *.Contracts assemblies only.
Related
- Modular monolith — how modules compose into a single process
- Architecture Diagrams — visual overview of the module dependency map
- Vertical Slice Architecture — how features are structured inside each module