9. What's Next¶
You built a library management system with two contexts, typed IDs, stored entities, commands, queries, full-text search, a REST API, domain events, background jobs, and integration events. Everything works in-memory. Every handler is testable. No database, no message broker, no infrastructure.
Here's what you've got:
- Library.Contracts — shared IDs and integration event topics
- Library.Catalog — books, authors, search, REST API, integration event handlers
- Library.Lending — patrons, loans, holds, domain events, jobs, REST API, integration event publishing
- Library.Tests — unit tests with spy access, behavior tests that work against in-memory or real infrastructure
Adding Real Infrastructure¶
Everything so far uses in-memory implementations — InMemoryBookStore, InMemorySearchIndex<T>, in-process event channels. That's by design. When you're ready for production, swap the backing infrastructure without changing any domain code:
builder.AddCatalogRuntime(rt =>
{
rt.AddCatalogStorePostgres(); // Swap InMemory → Postgres
rt.PublishToServiceBus<CatalogEvents>(); // Swap channel → Service Bus
});
Same commands. Same handlers. Same tests. Infrastructure is a deployment concern.
Where to Learn More¶
Guides¶
- Growing Your Application — when to add a third runtime, how the patterns scale
- Connecting Runtimes — deeper dive on EventQueue vs IntegrationEvents
- Deployment Topologies — same code, one process or many
- Project Structure — scaling the solution layout
- Testing Multiple Runtimes — per-context isolation, cross-context integration tests
Module Reference¶
Every module has its own docs with attributes, generated code reference, and diagnostics:
- Effects —
Eff<RT,T>composition, error handling, resilience - DataStore — entities, stores, lookups
- Dispatch — commands, queries, validation
- EventQueue — in-process domain events
- IntegrationEvents — cross-context event transport
- Jobs — background jobs, scheduling
- Search — full-text search
- Config — typed configuration with validation
- HttpClient — generated HTTP clients
- Testing — TestRuntime, assertions, integration testing