Settings for scaffolding out a bounded context for within your domain project.
A bounded context is a logical contextual boundary within your domain, in the same vein that it is used in Domain Driven Design (DDD). For example, in a clinical domain, I might have front desk, billing, laboratory, and reporting contexts.
| Name | Required | Description | Default |
|---|---|---|---|
| ProjectName | Yes | A simple string that will become the name of your solution within a bounded context. | None |
| DbContext | Yes | The db context setup for this project. | None |
| Entities | Yes | A list of entities to create database endpoints. | None |
| SwaggerConfig | No | The swagger configuration for this API. | None |
| Environment | No | The environment settings in launch settings for your local development. | None |
| Producers | No | The MassTransit producers in your project. | None |
| Consumers | No | The MassTransit consumers in your project. | None |
| Bus | No | The MassTransit message bus in your project. When used in this context, the environment properties should be set in the Environment property of the bounded context. | None |
| Port | No | The port that will be used on localhost for this project. | 5000 |
| UseSoftDelete | No | A boolean that dictates whether or not your BaseEntity and DbContext will be configured for a soft delete. | true |
| UseCustomErrorHandler | No | A boolean that dictates the type of error handler middleware. By default, the Hellang Problem Details package will be used for robustness, but if you want to reduce a dependncy and do custom error handling by setting this to true | false |
| IncludeGithubTestActions | No | A boolean that dictates whether or not to include the Github test actions workflow. | true |
Note that the ProjectName should NOT be the same as an entity name or it will cause namespace issues.
The example on the project tutorial covers how to add new bounded contexts.