Empowering developers with modular components for modern application development, centered around Domain-Driven Design principles.

• • Introduction
  • Documentation
  • Features
    • Common Infrastructure
    • Core Domain and Application
    • Execution, Messaging and Modularity
    • Security and Access
    • Presentation and Host
    • Storage, Scheduling and Utilities
    • Testing and Test Utilities
  • Libraries used (excerpt):
  • Example projects
  • Performance Benchmarks
  • GitHub Pages
    • Source structure
    • Which Markdown files get into the site
    • Add a new documentation page
    • Local preview and build
    • Publishing through GitHub Actions
    • Typical workflow for docs updates
  • Collaboration
  • Commit Policy
  • License

Introduction

The bITdevKit provides modular building blocks for modern .NET applications. It is centered around clean architecture, Domain-Driven Design, modular vertical slices and reusable infrastructure for real-world application concerns such as requests, messaging, queueing, storage, scheduling and presentation.

This repository contains the full source code, supporting docs and several example applications in ./examples that show how the framework can be composed in practice. The components are published as NuGet packages.

For the latest updates and release notes, please refer to the CHANGELOG.

Documentation

The documentation site is available at bridgingit-gmbh.github.io/bITdevKit.

The best entry point into the current documentation set is the Documentation and Introduction to DDD in bITdevKit.

Features

Common Infrastructure

• Common Extensions
• Common Utilities
• Common Serialization
• Common Options Builders
• Common Mapping
• Common Caching
• Common Observability Tracing

Core Domain and Application

• Domain
• Domain Events
• Event Sourcing
• Domain Repositories
• Domain Specifications
• ActiveEntity
• Domain Policies
• Rules
• Results
• Application Commands and Queries
• Application Events
• DataPorter

Execution, Messaging and Modularity

• Requester and Notifier
• Messaging
• Queueing
• Notifications
• Modules
• Pipelines
• Filtering
• Extensions

Security and Access

• Entity Permissions
• Fake Identity Provider

Presentation and Host

• Presentation Endpoints
• Console Commands
• CORS Configuration
• Exception Handling
• AppState

Storage, Scheduling and Utilities

• StartupTasks
• JobScheduling
• DocumentStorage
• FileStorage
• Storage Monitoring
• Log Entries

Testing and Test Utilities

• Fake Authentication for Integration Tests
• Testing Common XUnit

Libraries used (excerpt):

• Xunit
• EnsureThat
• Mapster
• FluentValidation
• FluentAssertions
• Humanizer
• Polly
• Scrutor
• Serilog
• Quartz
• Shouldly
• Testcontainer
• EntityFramework
• Azure Storage
• Azure ServiceBus
• Azure CosmosDb
• RabbitMQ

Example projects

• GettingStarted (Basic)
• BookFiesta (DDD)
• EventStore (CQRS)
• WeatherForecast

Performance Benchmarks

The bITDevKit includes a dedicated benchmark project using BenchmarkDotNet to measure the performance of core components such as the Requester (CQRS/MediatR alternative).

How to run benchmarks:

dotnet run -c Release --project benchmarks/Common.Benchmarks/Common.Benchmarks.csproj

• This will execute all benchmarks and generate detailed reports in the BenchmarkDotNet.Artifacts/results/ directory (HTML, Markdown, CSV).
• The default benchmark covers the baseline request/response pipeline. You can extend the benchmarks to cover additional scenarios and compare different configurations.

Why benchmarks?

• Ensure high performance and low allocations for core infrastructure.
• Detect regressions and compare with other libraries (e.g., MediatR).
• Guide optimization and architectural decisions.

For more details, see the Common.Benchmarks project in the benchmarks/ folder.

GitHub Pages

The repository includes a MkDocs-based GitHub Pages site with:

• a landing page under docs/site/
• curated technical docs synced from ./docs

Public site: https://bridgingit-gmbh.github.io/bITdevKit/

Source structure

• docs/site/
  • the site-specific source pages such as the landing page, getting started pages, templates page, styling, and helper scripts
• docs/
  • the framework documentation source that is selectively imported into the public site
• .github/pages/
  • the generated static MkDocs output

Which Markdown files get into the site

The sync step currently imports these files from ./docs into the public site:

• INDEX.md
• introduction-ddd-guide.md
• common-*.md
• features-*.md
• testing-*.md

The following are intentionally excluded from GitHub Pages:

• docs/adr/
• docs/presentations/
• docs/specs/
• src/**

Add a new documentation page

For a new Markdown page from ./docs to appear in GitHub Pages:

1. Add or update the Markdown file under ./docs.
2. Make sure its filename matches one of the currently imported patterns above.
3. If it should appear in navigation, add it to mkdocs.yml under the appropriate section.
4. Regenerate the site locally or push to main so GitHub Actions publishes it.

Local preview and build

Preview the full site locally with Docker:

pwsh -File ./docs/site/scripts/serve-pages.ps1

or use the VS Code Tasks for the same command. Build the full static site locally:

pwsh -File ./docs/site/scripts/build-pages.ps1

That build command performs these steps:

1. Synchronize the selected public docs from ./docs into docs/site/reference/
2. Build the MkDocs site in Docker
3. Write the generated static site to ./.github/pages/

Publishing through GitHub Actions

The Pages workflow is defined in pages.yml.

On each push to main, it:

1. checks out the repository
2. runs ./docs/site/scripts/build-pages.ps1
3. verifies that ./.github/pages/index.html was generated
4. publishes the generated site to the gh-pages branch

Typical workflow for docs updates

Typical documentation workflow:

1. Edit or add Markdown under ./docs
2. If needed, update mkdocs.yml so the page is reachable in navigation
3. Run pwsh -File ./docs/site/scripts/serve-pages.ps1 to preview the result
4. Run pwsh -File ./docs/site/scripts/build-pages.ps1 to generate the final static output
5. Commit and push to main to publish via GitHub Actions

Collaboration

Simply create a pull request with your ideas or contact us. Please refer to the Contribution Guide for more information.

Commit Policy

To keep history clear and searchable, contributions should use semantic commit messages based on the Conventional Commits specification.

Format:

<type>[optional scope]: <description>

Examples:

• feat(modules): add startup task registration
• fix(jobs): prevent duplicate scheduling on startup
• docs(readme): clarify contribution workflow

Policy:

• Use the Conventional Commits format for all repository contributions
• Keep the description in imperative mood and under 72 characters
• Prefer one logical change per commit
• Review git diff --staged before committing, or git diff if nothing is staged
• Check git status --porcelain to confirm the exact files included
• Never commit secrets or credentials

---

License

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