Endatix.Framework 0.7.0

Endatix.Framework

This package provides common plugin and extensibility points used to extend or customize the Endatix Platform. It allows developers to build and integrate custom functionality within the platform.

Installation:

dotnet add package Endatix.Framework

Recommended Usage:

For running and hosting the Endatix Platform, Endatix.Api.Host is the recommended main package as it simplifies the installation and setup process.

dotnet add package Endatix.Api.Host

Module kernel

Optional platform modules implement IEndatixModule. The host registers them via EndatixBuilder.UseModule({Name}Module.Instance), which scans the module assembly for MediatR handlers and FastEndpoints and calls ConfigureServices at finalization.

Startup migrations (two phases)

When Endatix:Data:EnableAutoMigrations is true, DatabaseMigrationService runs:

1. Core (always) — AppDbContext and AppIdentityDbContext are migrated automatically; no contributor registration required.
2. Modules (opt-in) — each module with its own DbContext calls AddDbContextWithMigrations<TContext> in ConfigureServices (registers DbContext + migration contributor).

Module persistence checklist

1. Create {Name}Module : IEndatixModule, IHasDbMigrations (+ IHasFeatureFlag when optional).
2. In ConfigureServices, call builder.AddDbContextWithMigrations<TContext>(...) from Endatix.Infrastructure.Data (registers DbContext + migration contributor).
3. Use a dedicated schema and module-owned Persistence/ folder for entities, configs, and migrations.
4. Prefer provider-split DbContext types (one snapshot per provider) over namespace-filtered single contexts when supporting PostgreSQL and SQL Server.
5. Do not add Setup.cs — all DI belongs on the module class.

Observability (startup)

Startup logging uses Microsoft.Extensions.Logging source generation — not Serilog APIs — so hosts can switch to OpenTelemetry without changing call sites.

Layer responsibilities

Framework exposes only generic primitives:

• EndatixEventIds — platform-wide stable EventId registry (claim a range before adding domain extensions)
• EndatixLoggerExtensions — LogOperationStarted, LogOperationCompleted, LogOperationSkipped, LogOperationFailed

Domain-specific messages (migrations, seeding, host builders) belong in collocated *LoggerExtensions types in Infrastructure or Hosting — not in Framework.

Event ID registry

EndatixEventIds follows the same grouping pattern as Actions — nested static classes per area, plus utility collections:

EndatixEventIds.Lifecycle.OperationStarted      // Framework
EndatixEventIds.Migrations.DbContextMigrated    // Infrastructure
EndatixEventIds.Seeding.SampleDataSeeded        // Infrastructure
EndatixEventIds.IdentitySeed.UserCreated        // Infrastructure
EndatixEventIds.Hosting.ModuleRegistered        // Hosting

EndatixEventIds.Ranges.MigrationsStart          // claim before adding IDs
EndatixEventIds.Migrations.All                  // all IDs in a group
EndatixEventIds.IsMigration(eventId)            // range helpers

Claim a block in EndatixEventIds.Ranges before adding domain extensions.

Usage

Always pass the caller's typed ILogger (e.g. ILogger<DatabaseMigrationService>) so logger category is preserved for tracing.

Use Framework primitives for lifecycle; domain wrappers for specialized messages:

// Framework — generic lifecycle
_logger.LogOperationStarted(MigrationOperations.ApplyDbMigrations);

// Infrastructure — domain-specific (collocated)
_logger.LogDbContextMigrated(nameof(AppDbContext), durationMs);

Existing domain wrappers:

OTEL attribute mapping

MEL placeholder → future log attribute:

See high-performance logging.

More Information:

For detailed installation instructions, please visit Endatix Installation Guide.