v0.10.0

Getting ready to freeze 1.0. DDK now publishes under its own Maven namespace, com.domaindrivenkit, which Maven Central can verify. Java packages stay com.ddk.*, so upgrading changes build files, not code. Auto-configurations follow one naming rule, and their @Bean methods are no longer public API. ddk-core stops bringing Hutool along. Release artifacts carry build provenance, and a central profile signs and bundles a release for Maven Central once publishing there is decided. CI runs in named stages and fails when a test is skipped. The upgrade guide lists the steps from 0.9.

Breaking

• The Maven groupId changes from com.ddk to com.domaindrivenkit, a namespace that DDK owns through its domain and that Maven Central can verify. Artifact IDs and Java packages (com.ddk.*) stay the same, so only build files change: the BOM import, every DDK dependency and -DarchetypeGroupId. scripts/ddk.sh reads the groupId of the version it installs, so older releases keep working with it
• Three auto-configurations take the Ddk prefix like the other fourteen: MybatisPlusAutoConfiguration is now DdkMybatisAutoConfiguration (it shared its simple name with MyBatis-Plus's own), WebAutoConfiguration is now DdkWebAutoConfiguration and WebOpenApiAutoConfiguration is now DdkWebOpenApiAutoConfiguration. Update spring.autoconfigure.exclude entries and tests that name them
• @Bean methods of the cache, event, MyBatis, Redis and web auto-configurations are package-private, as in the other starters. The container calls them; an application that called one directly creates the object itself or injects the bean

Added

• Release artifacts carry SLSA build provenance attestations. gh attestation verify <jar> --repo poppycoderr/domain-driven-kit checks that a jar or the BOM was built from this repository by the release workflow for that tag

Changed

• An event skipped because its version is not in the consumer's contract is logged at WARN only the first time per consumer and version, then at DEBUG. While v1 and v2 are published side by side, a consumer that only knows v1 no longer logs a warning for every v2 message
• ddk-core no longer brings Hutool in transitively; it never used it. ddk-mybatis and ddk-mybatis-starter, which do, declare hutool-core themselves. An application that uses Hutool directly and got it only through ddk-core declares it itself