EF Core Persistence

The decision describes the complete persistence replacement for its selected aggregates.

Does the decision name aggregates, evolution, transactions, queries, packages, and rollback?

Marked guidance: a reviewer answers this question.

Local EF Core adoption does not change ownership of other aggregate paths.

Does every unaffected aggregate path retain its baseline persistence behavior?

Marked guidance: a reviewer answers this question.

One provider gives the Command one atomic commit boundary.

EfCoreTransactionTests stage aggregate work through one selected provider.

Marked checkable: the tool named here checks it.

Independent provider commits cannot preserve one local aggregate invariant.

EfCoreTransactionTests assert no mixed Marten and EF Core aggregate repository writes.

Marked checkable: the tool named here checks it.

The decision makes provider ownership reviewable for each selected Command path.

Does the decision name each Command path's provider and its test evidence?

Marked guidance: a reviewer answers this question.

A Marten post-handler cannot commit EF Core-owned work.

EfCoreTransactionTests assert each command resolves only its selected provider post-handler.

Marked checkable: the tool named here checks it.

One local invariant requires one verified atomic persistence boundary.

Does each cross-provider invariant use one provider or a reviewed shared transaction?

Marked guidance: a reviewer answers this question.

Repository staging keeps write persistence outside Application handlers.

EfCoreWriteTests stage changes through the scoped DbContext.

Marked checkable: the tool named here checks it.

The selected post-handler owns the one Command commit.

EfCoreWriteTests assert handlers inject no DbContext and call no SaveChangesAsync.

Marked checkable: the tool named here checks it.

The interface defines the EF Core query boundary without exposing the Infrastructure DbContext. The permitted surface is the query types the interface exposes and the manifest-pinned Microsoft.EntityFrameworkCore package that declares them.

EfCoreReadTests assert one owned IApplicationDbContext and no wider EF surface.

Marked checkable: the tool named here checks it.

The provider implementation remains behind Application's query interface.

EfCoreReadTests assert the Infrastructure DbContext implements the owned query interface.

Marked checkable: the tool named here checks it.

EF Core adoption does not alter read ownership for Marten-backed aggregates.

EfCoreReadTests assert Marten query handlers retain IQuerySession.

Marked checkable: the tool named here checks it.

Handlers return shaped results without loading mutable aggregate state. No command enforces an invariant from a read projection.

EfCoreReadTests assert no tracking, authorized filters, deterministic limits, projections, and no invariant from a projection.

Marked checkable: the tool named here checks it.

IApplicationDbContext supplies the selected EF Core query boundary.

EfCoreReadTests assert no per-aggregate read-store interface pattern exists.

Marked checkable: the tool named here checks it.

Resolution at creation keeps the tenant out of every query, and the filter convention applies it to each tenant-owned set.

EfCoreReadTests assert tenant resolution at creation and tenant filters on owned sets.

Marked checkable: the tool named here checks it.

One post-handler commit preserves the Command's provider transaction boundary.

EfCoreCommitTests observe one post-handler SaveChangesAsync call per owned Command.

Marked checkable: the tool named here checks it.

Event delivery follows the same aggregate changes that the handler commits.

EfCoreCommitTests classify and stage Domain events correctly.

Marked checkable: the tool named here checks it.

EF Core-owned durable work remains in the selected provider transaction.

EfCoreCommitTests assert EF Core durable Commands commit no Marten session.

Marked checkable: the tool named here checks it.

The DbContext transaction makes the outbox record and business work durable together.

EfCoreOutboxTests stage message and business work through one DbContext.

Marked checkable: the tool named here checks it.

A Marten outbox transaction cannot atomically commit an EF Core aggregate change.

EfCoreOutboxTests assert EF Core Commands write no outbox record through Marten.

Marked checkable: the tool named here checks it.

Relational mapping behavior belongs to the provider-owning layer.

EfCoreMappingTests assert EF Core mappings use Infrastructure-owned configuration classes.

Marked checkable: the tool named here checks it.

Explicit configuration makes storage contract changes visible in code review and migrations.

Does the mapping review record every declared relational configuration category?

Marked guidance: a reviewer answers this question.

The aggregate remains the owner of lifecycle state and state-specific business facts.

A relational column holds the active state record and its discriminator, which is the same contract the baseline provider stores in its document. The column never holds an enumerated integer, because that discards the state-specific facts the record carries and reintroduces the shape litespec/backend/domain#model-every-closed-set-of-domain-values-as-a-closed-type-hierarchy removes. A state case with its own fields maps to an owned type or to its own table. The discriminator selects which one a read materializes.

EfCoreStateTests retain the aggregate's one Domain state value.

Marked checkable: the tool named here checks it.

Relational storage can use columns while Domain retains its state-record hierarchy.

EfCoreStateTests assert no relational lifecycle flags or duplicate nullable state values.

Marked checkable: the tool named here checks it.

A direct mapping needs complete provider behavior for every sealed state case.

EfCoreStateTests materialize, track, and round-trip every state case.

Marked checkable: the tool named here checks it.

The Infrastructure repository maps the persistence type to and from the Domain hierarchy.

EfCoreStateTests map valid discriminator values to Domain states.

Marked checkable: the tool named here checks it.

New state values affect stored rows and application versions that read them.

PostRow maps state_type, published_at, and archived_at to one PostState record.

Does the new state review cover migration, mixed versions, rollback, and a fixture?

Marked guidance: a reviewer answers this question.

The migration is the explicit reviewed description of relational schema evolution.

EfCoreMigrationsTests assert EF Core schema diffs include a generated migration.

Marked checkable: the tool named here checks it.

Each item can affect deployment safety or data recovery.

Does the migration review cover every declared storage and rollback effect?

Marked guidance: a reviewer answers this question.

Release-owned execution controls ordering and evidence for schema work.

EfCoreMigrationsTests place migration application before replica startup in the release record.

Marked checkable: the tool named here checks it.

The three artifacts show intended migration source and resulting relational change.

EfCoreMigrationsTests assert each migration commit holds migration, snapshot, and reviewed SQL.

Marked checkable: the tool named here checks it.

Both initial setup and upgrade paths need tested relational evolution.

The previous release database is the schema of the last released artifact, not the schema of the previous commit. The test builds it by applying that artifact's migrations to an empty database, then applies the current ones on top. A test that starts from the current migrations minus one proves that the last migration applies, which is the case least likely to be broken.

EfCoreMigrationsTests run from empty and previous-release databases.

Marked checkable: the tool named here checks it.

Replica startup does not own hosted database schema change.

EfCoreMigrationsTests assert startup calls none of the prohibited schema APIs.

Marked checkable: the tool named here checks it.

The token connects a caller's expected aggregate version to EF Core write detection.

EfCoreConcurrencyTests carry expected version and use the configured EF Core token.

Marked checkable: the tool named here checks it.

Application exposes a project-owned conflict rather than an EF Core exception type.

EfCoreConcurrencyTests map the provider exception to the Application contract.

Marked checkable: the tool named here checks it.

A retry can rerun Domain behavior against state that the caller did not approve.

EfCoreConcurrencyTests prove no complete Command automatic retry.

Marked checkable: the tool named here checks it.