Domain
DDD boundaries / language
Base Template DDD
A developer platform that turns enterprise application foundations into a governed workflow through DDD, CQRS, a deep CLI and a visual Studio.
Foundation.NET 10 / DDD / CQRS
CLI110+ commands
Workflows14 categories
DataSQL Server / PostgreSQL / Oracle
$ btd doctor ✓ architecture healthy ✓ providers configured $ btd studio --dev
CLICLI
WorkflowsWorkflows
FoundationFoundation
DataData
00 / 09Workbench
Chapter 00
02 / BTD
02 / BTD
Workbench
The developer is the product user.
BTD is presented as a workbench rather than a starter template. Architecture rules, commands and visual tooling are interfaces for engineers building larger systems.
Architecture becomes a developer workflow.
The developer is the product user.
The developer is the product user.
Chapter 01
02 / BTD
02 / BTD
Why a platform
Reuse should preserve understanding rather than hide it.
Repeated enterprise concerns become expensive when each codebase invents them independently. BTD turns repeatable foundations into documented, inspectable capabilities.
01
Make boundaries visible
Prefer explicit modules, state and contracts over hidden magic.
02
Keep workflows operable
Architecture earns its place by helping real people use and change the system.
03
Design for change
Build enough structure to protect the product without premature complexity.
Chapter 02
02 / BTD
02 / BTD
DDD / CQRS foundation
Architecture is a tool for change, not ceremony.
Domain boundaries, application use cases and infrastructure concerns remain explicit. CQRS supports clear control flow without requiring distributed complexity.
Application
CQRS / use cases
Workbench
CLI / Studio / rules
Infrastructure
Auth / data / audit
Chapter 03
02 / BTD
02 / BTD
CLI
Automation is valuable when it keeps consequences visible.
The CLI exposes workflows across generation, diagnostics, architecture, setup and project operations. It is a real developer interface rather than decorative terminal text.
BTD
in use.
Interfaces, states and developer tooling are shown as evidence of product behavior rather than a technology logo collection.
02Structure
you can inspect.
The visual connects what a user touches to the decisions underneath it.
BTChapter 04
02 / BTD
02 / BTD
Studio
Command line and visual tooling serve different moments in the same workflow.
Studio provides a wider visual view of modules, architecture and tooling. It complements the CLI rather than replacing it.
BTD
in use.
Interfaces, states and developer tooling are shown as evidence of product behavior rather than a technology logo collection.
02Structure
you can inspect.
The visual connects what a user touches to the decisions underneath it.
BTChapter 05
02 / BTD
02 / BTD
Architecture rules
Governance should give feedback early.
Rules and diagnostics make intended boundaries observable. Teams should be able to see drift close to the change that caused it.
01
Make boundaries visible
Prefer explicit modules, state and contracts over hidden magic.
02
Keep workflows operable
Architecture earns its place by helping real people use and change the system.
03
Design for change
Build enough structure to protect the product without premature complexity.
Chapter 06
02 / BTD
02 / BTD
Multi-database
Providers change; domain behavior should not.
SQL Server, PostgreSQL and Oracle support reflect real enterprise variation. Provider flexibility is treated as an infrastructure capability rather than a logo wall.
Domain
DDD boundaries / language
Application
CQRS / use cases
Workbench
CLI / Studio / rules
Infrastructure
Auth / data / audit
Chapter 07
02 / BTD
02 / BTD
Enterprise capabilities
Capabilities share conventions because the application has to feel like one system.
Authentication, authorization, tenancy, audit, localization and versioning sit inside one coherent foundation.
BTD
in use.
Interfaces, states and developer tooling are shown as evidence of product behavior rather than a technology logo collection.
02Structure
you can inspect.
The visual connects what a user touches to the decisions underneath it.
BTChapter 08
02 / BTD
02 / BTD
Developer experience
Developer experience is a maintained contract.
Good developer platforms optimize for clarity, fast feedback and predictable behavior. CLI, Studio and documentation are one product surface around the architecture.
Foundation
Developer experience is a maintained contract.
CLI
Developer experience is a maintained contract.
Studio
Developer experience is a maintained contract.
Governance
Developer experience is a maintained contract.
Chapter 09
02 / BTD
02 / BTD
Ownership
Tooling is product work.
BTD shows product thinking applied to engineering infrastructure. The user happens to be a developer, but the standards for clarity, feedback and usability stay the same.
Architecture becomes a developer workflow.
Tooling is product work.
Tooling is product work.