Skip to content

BaseTemplate DI Extensibility

Purpose

This page defines the internal implementation contract for DI orchestration extensibility between ConnectSoft.BaseTemplate and specialized templates (for example Identity).

Goals:

  • reduce duplicated startup/DI orchestration code
  • preserve BaseTemplate defaults as a stable baseline
  • allow targeted add/replace behavior through explicit hooks

Standard terms used in this internal guide:

  • base + add
  • replace whole step
  • default-preserving hooks
  • submodule refresh

Core Model

The model uses three parts:

  • MicroserviceRegistrationExtensions as host entry points
  • DefaultMicroserviceRegistration to preserve default BaseTemplate behavior
  • MicroserviceRegistrationBase protected virtual hooks for derived templates

Extension Patterns

base + add

Use when derived templates should keep base behavior and append custom registrations.

Examples:

  • extra localization resources
  • additional named/typed HTTP clients
  • template-specific metrics

replace whole step

Use when derived templates need different behavior for one registration stage.

Examples:

  • health check subset and tags
  • problem details mapping strategy
  • migration assembly routing and migrator registration

Hook Surface (high-level)

MicroserviceRegistrationBase includes hooks across:

  • registration staging before/after domain registration
  • cross-cutting concerns (localization, HTTP clients, metrics, security, rate limiting, header propagation, request timeouts, compression)
  • API stack (problem details, REST infra, Swagger, gRPC)
  • persistence/migrations (GetMigrationAssembly, fluent migrator registration, NH persistence)
  • observability and health checks
  • endpoint mapping and shutdown lifecycle

Migration Checklist (Derived Templates)

  1. Identify duplicated DI orchestration in derived template ApplicationModel.
  2. Keep BaseTemplate default flow as source of truth.
  3. Move template-specific behavior to MicroserviceRegistrationBase overrides.
  4. Remove mostly identical orchestration code from derived template.
  5. Respect submodule boundaries:
    • do not edit submodule content directly
    • refresh submodule to consume BaseTemplate updates
  6. Verify with build + startup smoke checks (health, endpoints, middleware order).