DotNetSolutionKit (dotskit) is a configurable dotnet new template and lifecycle toolkit for standardized .NET solutions.
It provides ready-to-use architectural building blocks, modules, and integrations with infrastructure services that can be combined through flags to create different solution variants tailored to a team's needs and infrastructure. It generates microservice solutions based on DDD and Clean Architecture, with CI, deployment, and testing, adds services, connects modules to them, and upgrades solutions to new template versions while preserving the team's code. The generated solution remains an ordinary .NET project owned by the team, allowing them to focus on the architecture of the solution they are building and its business logic.
What the template gives a solution, at a glance:
mindmap
root((DotNetSolutionKit))
Generation
Common once, a service per run
Dotted names in every part
Flags
PostgreSQL or SQL Server
Hangfire jobs
Message bus with outbox or direct
Secrets from Infisical or Vault
S3 object storage
ClickHouse
MongoDB beside the main database
Email with a sandbox
Audit journal through the outbox
Feature flags
API diff on pull requests
Access rules over a tenant tree
API gateway on YARP
CI on GitHub Actions
Deploy with compose or Kubernetes
NUnit or xUnit
Rules and skills for an AI agent
Architecture
Layers with explicit references
Domain events in three phases
Repositories on specifications
RFC 9457 problems
Validation answers 422
Permissions from the token
One JSON format
Operations
One Dockerfile, unchanged images stay
Health and readiness
Migrations and schema guard under a lock
Dependencies switched off in configuration
Version set by hand
Tests
Sociable service tests
A database per test
Integration only for the real database
- What the template gives: what a solution gets, the principles, the cost and the risks
- Generating a solution: install, parameters, dotted names, running locally
- dotskit: the tool that makes a solution, adds services and flags to it, describes a solution made without it and upgrades a solution, keeping the team's changes
- Versions of the template: v1 and v2, what changed, how to update
- Working with AI agents: the rules and skills a solution gets
- Projects and layers
- Web layer: the host and the pipeline every service shares
- Errors: RFC 9457 problems
- Validation and pagination
- Authentication and permissions
- Persistence: schemas, migrations, repositories, search
- Settings: their sources, and what changes while a service runs
- Domain events
- Testing
- Background jobs: Hangfire,
--Hangfire - Message bus: MassTransit,
--Messaging - Secrets from Infisical or Vault:
-I,--Vault - Feature flags:
--FeatureFlags - API diff:
--DiffApi - CI on GitHub Actions:
--GitHubCiCd - Access rules over a tenant tree:
--HierarchyRules - Object storage: S3-compatible,
--Storage - ClickHouse:
--ClickHouse - MongoDB:
--MongoDB - Notifications: email,
--Notify - Audit journal:
--Audit, with--Messaging outbox - API gateway: YARP,
--ApiGateway
- Docker: one Dockerfile, only changed services rebuilt
- Deployment: docker compose or Kubernetes,
--Deploy - Health:
/healthand/ready - Startup checks
- Switching dependencies off: run without the database, the jobs, the bus or the secret store, and turn them on later
Where the template departs from a common practice, and why.
- ADR-001: Domain events run in three phases tied to the transaction
- ADR-002: Repositories take queries as specifications
- ADR-003: The API document is read from the built application
- ADR-004: The product version is set by hand
- ADR-005: How a service is tested
- ADR-006: JSON metadata keys
What is planned, and where the template ties a team to one technology.