Skip to content

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:

  • EffectsEff<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

Infrastructure Packages

  • Postgres — BYOC DbContext for DataStores
  • Aspire — Service Bus topology, config bridges
  • Azure — Table Storage, Service Bus transport