Skip to main content

Asset Development Seeding

Summary​

Source-backed account of the Development-only seeder that plants a small, representative set of assets so a fresh local database has usable data. It runs once, is idempotent, and never executes outside Development.

Audience​

Backend engineers, database reviewers, architects, QA, support, operations, security reviewers, and product owners.

Overview​

DevelopmentSeeder runs immediately after the automatic migration step, and only in the Development environment. It targets a single development tenant, checks for an idempotency marker with query filters bypassed, and if the marker is absent, seeds three assets through the aggregate so that lifecycle events land in the outbox exactly as they would in normal operation. In production the seeder does not run.

Confirmed persistence behavior​

  • Trigger. The seeder is invoked after the migration step completes, on service startup, in Development only.
  • Environment restriction. Seeding is gated to the Development environment; other environments are never seeded.
  • Tenant selection. All seed data is written under a single development tenant. (The numeric tenant id and key are internal and are not reproduced here.)
  • Idempotency marker check. Before seeding, the seeder looks for a specific marker asset using an explicit predicate combined with a query-filter bypass, so the check can see the marker regardless of the active tenant context.
  • Seed categories. When the marker is absent, the seeder creates three assets:
    • one available inventory asset;
    • one issued asset, created and then assigned through the aggregate so that the AssetAssigned event is written to the outbox;
    • one pending request, created so that the AssetRequested event is written to the outbox.
  • Aggregate-driven emission. Because seeding goes through the aggregate rather than raw inserts, domain events are dispatched to the outbox exactly as in live flows.
  • Idempotency / duplicate prevention. If the marker asset already exists, the seeder bails without writing anything, so repeated startups do not duplicate seed data.
  • Source ownership. The seeder lives in the Infrastructure layer (DevelopmentSeeder).
  • Production behavior. The seeder is not executed outside Development; production data is never seeded by this path.

Classification​

Implemented Development-only, idempotent, aggregate-driven seeding.

Requires confirmation​

  • Any non-Development bootstrap or reference-data provisioning is out of scope for this seeder and would require confirmation.
  • Governance for refreshing or resetting local seed data beyond the built-in idempotency marker.

Diagram​

See Also​

Keywords​

  • Asset seeding
  • Development data
  • Draft database documentation

Source References​

  • microservices/src/asset-service/Infrastructure/DevelopmentSeeder.cs
  • microservices/src/asset-service/Program.cs
  • microservices/src/asset-service/Domain/Asset/Asset.cs

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-17
  • Review cycle: Quarterly