Starter Domain Reviewer

Starter-Domain Reviewer

Guide for AI agents reviewing changes in sbs/starter-domain — the shared, framework-neutral domain layer used by every Axelix Spring Boot starter (axelix-spring-boot-2-starter, axelix-spring-boot-3-starter, axelix-spring-boot-4-starter).

Apply this skill whenever a PR creates, modifies, or deletes files under sbs/starter-domain/, including build.gradle.kts.

Module purpose

starter-domain is the module that is supposed to represent the domain logic of our starters that is independent from Spring, Hibernate, Junit or any technology that may differ in various different spring boot versions.

As a result, starter-domain must NEVER include the dependencies like:

• spring-boot
• hibernate
• jackson
• thymeleaf

and so on - anything that is subject to change in between major spring boot versions - cannot be used in starter-domain. This is an absolute must.

Note that however for the dependencies that are not ending up in the end-user's classpath - we're free to choose whatever we want. But again, since we must complie for java 11, we cannot use e.g. Spring Boot Test version 3, since it requires java 17. So for "test" dependencies this rule is generally eased, but again, we must consider the fact that we compile to java 11 bytecode.

starter-domain is supposed to be used by all spring boot starters that we have. As a result, the code that is written in the starter-domain module is supposed to be used in the java verisons from 11 up to the very latest. We do not support java 8.

When to apply

• PR diff touches sbs/starter-domain/** (main, test, concurrencyTest, or build.gradle.kts).
• User asks to review starter-domain, starter shared logic, or framework-neutral starter code.
• User asks whether starter-domain changes are merge-ready.

If starter-domain is untouched, do not apply unless the user explicitly asks about starter-domain impact of changes elsewhere (e.g. a new type referenced from starter-domain).

Review workflow

1. Identify scope — List changed files under sbs/starter-domain/ (git diff / PR files API). Include build.gradle.kts and both src/main and src/test (plus src/concurrencyTest if present).
2. Check production classpath — Inspect sbs/starter-domain/build.gradle.kts for any new/changed api, implementation, compileOnly, or runtimeOnly dependencies. Flag anything version-sensitive or framework-specific.
3. Scan main sources — In src/main/**, search imports and public API signatures for forbidden framework types (see Forbidden in production).
4. Check Java baseline — Confirm options.release = 11 / JvmTarget.JVM_11 remain set; scan for Java 17+ language APIs or bytecode-only features.
5. Review design fit — Does new logic belong in starter-domain, or in a version-specific starter module? Prefer abstractions over framework types.
6. Review tests separately — Apply test-reviewer for test quality; apply this skill's test-dependency rules below.
7. Report using the output format at the end. Block merge on any 🔴 finding.

Standards

1. Production dependencies — merge-blocking

Rule: Nothing that varies across Spring Boot major versions may appear on the production classpath of starter-domain.

Forbidden dependency groups (non-exhaustive — block anything in the same category):

Allowed production dependencies (typical):

• project(":common:auth"), project(":common:api"), project(":common:domain"), project(":common:utils") — already declared as api
• JDK / java.*, javax.sql.* (e.g. DataSource)
• org.jspecify:jspecify (via shared plugin)
• Other small, version-stable libraries only if they do not pull Spring/Jackson/Hibernate onto the end-user classpath

Flag as 🔴 when:

• build.gradle.kts adds implementation / api / runtimeOnly for any forbidden group above.

Flag as 🟡 when:

• compileOnly is used for a framework type (discouraged in starter-domain; prefer string-based detection or an interface in starter-domain with impl in the starter module).

2. No framework types in main code — merge-blocking

Production code (src/main/**) must not import or expose types from version-sensitive frameworks.

Scan commands (run on changed main files or whole module when in doubt):

rg 'import (org\.springframework|org\.hibernate|com\.fasterxml|org\.thymeleaf|jakarta\.servlet|javax\.servlet)' sbs/starter-domain/src/main

Acceptable patterns already in the codebase:

• Abstraction interfaces with framework-specific implementations in starter modules — e.g. EndpointPathMatcher in starter-domain; Spring PathPattern adapter lives in axelix-spring-boot-*-starter.
• String-based class presence checks — e.g. SpringCloudVersionResolver referencing "org.springframework.cloud.client.CommonsClientAutoConfiguration" without importing Spring.
• JDK and common/* types — e.g. com.axelixlabs.axelix.common.domain.http.HttpMethod instead of org.springframework.http.HttpMethod.
• Javadoc references to Spring class names (documentation only, not compile-time deps).

Flag as 🔴 when:

• src/main imports org.springframework.*, org.hibernate.*, com.fasterxml.jackson.*, org.thymeleaf.*, etc.
• Public method signatures, fields, or return types use framework classes (ApplicationContext, BeanFactory, PathPattern, ObjectMapper, EntityManager, …).
• Spring/Jakarta annotations on production types (@Component, @Configuration, @Autowired, @Transactional, …).
• Production code uses Spring-specific utilities when a JDK or starter-domain utility exists (ClassUtils / ProxyUtils in this module — not Spring's).

Flag as 🟡 when:

• Logic duplicates Spring behavior inline with a comment linking to Spring source — acceptable if unavoidable, but suggest extracting a named utility or documenting why an interface boundary is not possible.