DotNetSolutionKit (dotskit)

Made by Vladimir Savkin at sawking.tech.

Site: dnsk.sawking.tech. Documentation, in English and Russian: dnsk.sawking.tech/docs.html.

Version 2 breaks version 1. Do not apply this template with --force over a solution generated from v1: namespaces, project references, package management, versioning and the shape of error responses changed, and the overwritten solution will not build. Use v2 for new solutions; port changes into existing ones by hand, using what changed in v2.

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 it gives a solution in full - the principles, the economics, the cost: what the template gives.

Install and generate

dotnet new install SawKing.DotNetSolutionKit

# the shared Common projects, the solution file and the first service
dotnet new DotNetSolutionKit -N MyCompany -P MyProduct -S Orders --Solution

# every further service
dotnet new DotNetSolutionKit -N MyCompany -P MyProduct -S Billing

The package is SawKing.DotNetSolutionKit on nuget.org; every release also carries it as a .nupkg file. To try the template from a clone: dotnet new install /path/to/DotNetSolutionKit/template.

From 2.8 the tool dotskit does the same with shorter commands, adds a flag to a service generated earlier, and upgrades a solution to a newer version of the template, keeping the team's changes by a three-way merge:

dotnet tool install -g SawKing.DotsKit.Tool

dotskit new -N MyCompany -P MyProduct -S Orders   # in an empty folder: the solution and its first service
dotskit new -S Billing --Storage true             # in the solution: one more service
dotskit new -S Orders --MongoDB true              # in the solution: a flag for a service it has
dotskit init                                      # in a solution made without dotskit: describe it in its manifest
dotskit upgrade                                   # in the solution: bring it to the tool's version of the template

What the generated solutions look like: DotNetSolutionKit.Samples, a branch each for a single service, a gateway with services and the full kit, regenerated from every release with their CI running, and full-dev, generated from dev, where the next release is built. The samples page shows their files and how their CI ran.

Parameter	Default	What it does
-N, --NamespaceRoot	MyCompany	Organization name, the root namespace. May be dotted.
-P, --ProductName	Product	Product name. May be dotted.
-S, --ServiceNameOrCustom	Service	Service name. May be dotted.
--Solution	false	Generates the solution: Common, All.sln and the root files, with the first service. Without it, only the service folder, into a solution already there.
--Database	postgres	Database: postgres or mssql (SQL Server).
-H, --Hangfire	true	Background jobs on Hangfire.
--Messaging	none	Message bus: outbox or direct.
-I, --Infisical	false	Secrets and settings from Infisical.
--Vault	false	Secrets and settings from HashiCorp Vault.
--DiffApi	false	API contract diff on pull requests.
--GitHubCiCd	false	CI on GitHub Actions: build, tests on real servers, coverage on demand, secret scan.
-FF, --FeatureFlags	false	Feature flags.
--HierarchyRules	false	Access rules over a tenant tree.
--Storage	false	Object storage, S3-compatible.
-CH, --ClickHouse	false	ClickHouse: connections, schema check, readiness.
--MongoDB	false	MongoDB beside the main database: the client, the service's database, readiness.
--Notify	none	Channels of notifications: email - through SMTP or Graph API, with a sandbox outside Production; with --Messaging other services ask for it by a bus command.
--TestFramework	nunit	Test framework of the service's tests: nunit or xunit (v3).
--Audit	false	Audit journal of entity changes, through the outbox; with --Messaging outbox.
--ApiGateway	false	An API gateway on YARP in place of a service, into a solution already there (without --Solution).
--Deploy	compose	Deployment files: compose, k8s or none.
--Agent	claude	Rules and skills for an AI agent: claude, opencode or none.
--HttpPort	free port	Port in launchSettings.json and on the host under compose.

Details, dotted names and running locally: generating a solution.

Documentation

Everything else is in docs: the architecture, each feature, operations, the decisions behind the parts that depart from common practice, and the roadmap. The site shows the same documents with a menu and rendered diagrams, in English and Russian.

What each version brings: version.json and the releases. How versions are made: contributing.

License

This project is licensed under the MIT License. See the LICENSE file for details.