Database Migrations
Relevant source files
The following files were used as context for generating this wiki page:
- WebApplications/Scheduling.WebApi/DatabaseMigrator.cs
- claude.md
- Core/Scheduling/Scheduling.Infrastructure/Persistence/Migrations/20260116222802_InitialCreate.cs
- Core/Scheduling/Scheduling.Infrastructure/Persistence/Migrations/20260327124204_AddOutboxTables.cs
- WebApplications/Identity.WebApi/Migrations/ConfigurationDb/20260420185220_InitialIdentityServerConfigurationDbMigration.cs
- WebApplications/Identity.WebApi/Migrations/PersistedGrantDb/20260420185231_InitialIdentityServerPersistedGrantDbMigration.cs
- WebApplications/Identity.WebApi/Migrations/20260420184520_InitialIdentity.cs
- Core/Billing/Billing.Infrastructure/Persistence/Migrations/20260310141527_InitialCreate.Designer.cs
Database Migrations in this project facilitate the evolutionary design of the database schema across different bounded contexts, including Scheduling, Billing, and Identity. The project utilizes Entity Framework Core (EF Core) Migrations to manage schema changes, ensuring that the SQL Server database remains in sync with the Domain-Driven Design (DDD) aggregate models.
The system employs a multi-context migration strategy where each microservice or bounded context maintains its own set of migrations within its respective Infrastructure project. This allows for independent scaling and schema evolution for different parts of the system, such as patient scheduling and financial billing.
Sources: claude.md:28-36, WebApplications/Scheduling.WebApi/DatabaseMigrator.cs:1-10
Migration Lifecycle and Execution
The project distinguishes between development-time migration application and production-ready deployment pipelines. During local development, migrations can be applied automatically on application startup to streamline the developer experience.
Automated Local Migrations
For the Scheduling bounded context, a DatabaseMigrator class implements IHostedService to apply pending migrations automatically when the application starts, provided the environment is set to Development.
The diagram above shows the conditional logic for applying migrations during the application startup sequence.
Sources: WebApplications/Scheduling.WebApi/DatabaseMigrator.cs:12-32
Production Deployment Strategy
In non-development environments (Staging/Production), migrations are handled via external deployment pipelines. Methods include:
- Standard EF Core CLI tools:
dotnet ef database update - Migration Bundles: Self-contained executables containing the migration logic and the EF Core runner.
Sources: WebApplications/Scheduling.WebApi/DatabaseMigrator.cs:5-9
Bounded Context Schemas
Each bounded context manages specific tables related to its domain aggregates. Below are the primary migrations identified in the project:
Scheduling Context
Manages patient information and event-driven infrastructure (Outbox/Inbox).
| Migration Name | Key Tables Created/Modified | Description |
|---|---|---|
InitialCreate | Patients | Creates the base patient entity table. |
AddOutboxTables | Scheduling_InboxState, Scheduling_OutboxState, Scheduling_OutboxMessage | Adds MassTransit transactional outbox support. |
Sources: Core/Scheduling/Scheduling.Infrastructure/Persistence/Migrations/20260116222802_InitialCreate.cs:14-30, Core/Scheduling/Scheduling.Infrastructure/Persistence/Migrations/20260327124204_AddOutboxTables.cs:14-111
Billing Context
Manages financial profiles and payment methods. The schema includes owned entities for value objects like PaymentMethod.
Identity Context
Utilizes Duende IdentityServer with three distinct database contexts, each requiring independent migrations:
- IdentityDbContext: Stores ASP.NET Core Identity users and roles.
- ConfigurationDbContext: Stores IdentityServer configuration (Clients, Resources, Scopes).
- PersistedGrantDbContext: Stores operational data (Authorization codes, Refresh tokens).
Sources: WebApplications/Identity.WebApi/Migrations/20260420184520_InitialIdentity.cs:14-230, WebApplications/Identity.WebApi/Migrations/ConfigurationDb/20260420185220_InitialIdentityServerConfigurationDbMigration.cs:14-550, WebApplications/Identity.WebApi/Migrations/PersistedGrantDb/20260420185231_InitialIdentityServerPersistedGrantDbMigration.cs:14-160
Implementation Details
MassTransit Outbox Schema
To support reliable messaging, the Scheduling context includes specific tables for the MassTransit Entity Framework integration.
The diagram represents the relationship between message state tables used to ensure "at-least-once" delivery and idempotency.
Value Object Mapping
Value objects, such as PaymentMethod in the Billing context, are mapped using EF Core's "Owned Entities" pattern. This ensures that the value object properties are persisted as columns within the owner's table rather than a separate table.
| Field in DB | Source Property | Constraint |
|---|---|---|
PaymentMethodCardholder | CardholderName | MaxLength(200) |
PaymentMethodLast4 | Last4Digits | MaxLength(4) |
PaymentMethodType | Type | MaxLength(50) |
Summary
The Database Migration system provides a robust framework for handling schema changes across a distributed DDD architecture. By segregating migrations by bounded context and utilizing automated migrators for development, the project maintains high developer velocity while ensuring schema integrity and supporting advanced patterns like the Transactional Outbox.