3.1.0

The module names its generated code. [assembly: Module] now wins for every generated name, and DDD_Module is the default beneath it. This renames generated methods in some projects that declare a module; The names of generated registrations has the cases and what to do in each. The changelog has the full entry.

Changed

Add{Module}Converters, Add{Module}IntegrationEvents and Add{Module}GraphQlRuntimeBindings take their name from the first of three places that has one, the order {Module}EventNames already had:

Where	Who it is for
[assembly: Module("Ordering")]	A module. It always wins.
<DDD_Module>Shop</DDD_Module>	A project that is no module. A Directory.Build.props can set it for a whole folder.
The assembly name, dots removed	A project with neither.

A project without the attribute is not affected. A project with it is renamed when it set no DDD_Module, or another name:

The project has	3.0.1	3.1.0
The attribute and the same DDD_Module	AddOrderingConverters	AddOrderingConverters
The attribute and no DDD_Module	named after the assembly	AddOrderingConverters
The attribute and another DDD_Module, such as OrderingContracts	AddOrderingContractsConverters	AddOrderingConverters

Two assemblies, one module

A module and its contracts project give their registrations the same name. Add{Module}Converters and Add{Module}GraphQlRuntimeBindings call the ones of the module's other assemblies they reference, so a context or a schema makes one call for the module. Another module that references only the contracts calls the contracts' method, under that same name. See Two assemblies, one module.

Package ids

3.x is still published as Temp.DDDToolkit.*:

dotnet add package Temp.DDDToolkit --version 3.1.0