| name | code-review |
| description | Project-specific review checklist for this repository (DDD + Event Sourcing + Axon Framework 5 invariants). Use when: (1) reviewing code changes, a diff, or a pull request in this repository, (2) user says 'review', 'code review', 'check this change', (3) any automated review action runs for this repo. |
Code Review Checklist
Project-specific invariants to verify when reviewing changes in this repository.
These complement (not replace) general review practice: correctness, security,
performance, and missing tests.
Event Sourcing invariants
- Exhaustive
when (event) in evolve() — must switch over the sealed
interface with an explicit branch per subtype. No else -> branch, ever.
No-op branches (is SomeEvent -> state) are required and intentional —
they document a conscious "this event doesn't affect my state here" decision.
@EventSourcingHandler only on state-mutating events — branches that
return state unchanged must NOT have a corresponding handler.- Every state-mutating branch has a test for that state transition.
decide() and evolve() stay pure — no side effects, no infrastructure
dependencies in the Domain section.
Testing invariants
gameMetadata passed to every event() and command() call in tests —
events without metadata break MetadataSequencingPolicy and cause processor
failures with shared Testcontainers.- Integration tests use
@HeroesAxonSpringBootTest, never bare
@AxonSpringBootTest.
- Prefer constructor injection over field injection, also in tests.
Domain modeling invariants
- Value classes validate invariants in
init blocks — domain concepts
(Day, Gold, Quantity, …) must reject invalid values at construction.
- All domain events implement
HeroesEvent; module events extend their own
sealed interface (e.g. DwellingEvent).
- State classes are
internal; commands are public.
Slice structure invariants
- One slice per file (
FeatureName.Slice.kt) with Domain / Application /
Presentation sections.
- Feature flags — every new slice needs
@ConditionalOnProperty plus
entries in application.yaml and Spring configuration metadata.
- REST endpoints follow
games/{gameId}/...; player ID via X-Player-ID
header; game-scoped singletons use a fixed path segment, not a path variable.
Verification
Prefer the narrowest check: run the affected slice's test class
(./mvnw test -Dtest=FeatureNameTest), not the whole suite.
