asmhatre
b4a623b889
Separate write/read DataSources, a JPA command side, and two interchangeable projection listeners (sync and @Async) demonstrating the real latency-versus- freshness trade-off CQRS forces. Includes a reflection-based proof that the query side has no dependency on the write side, and a real failure/fix transcript for the -parameters compiler flag this standalone reactor doesn't inherit from spring-boot-starter-parent.
18 lines
1.1 KiB
Plaintext
18 lines
1.1 KiB
Plaintext
$ mvn -pl cqrs test -Dtest=QuerySideArchitectureTest
|
|
(plain JUnit reflection against the compiled OrderQueryController class -- no Spring
|
|
context started, because this is a claim about the class file, not about runtime wiring)
|
|
|
|
field readJdbcTemplate : org.springframework.jdbc.core.JdbcTemplate
|
|
OrderQueryController constructor parameter types: [class org.springframework.jdbc.core.JdbcTemplate]
|
|
|
|
[INFO] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0
|
|
|
|
The whole proof is in those two lines: OrderQueryController has exactly one declared
|
|
field and exactly one constructor parameter, and both are JdbcTemplate -- not
|
|
OrderRepository, not an EntityManager, not anything from the com.ankurm.cqrsdemo.command
|
|
package. A reviewer does not have to trust the Javadoc comment on the class or remember
|
|
to check it by hand on the next change; this test fails the build the moment anyone adds
|
|
a write-side dependency to the query side, the same way the hexagonal-architecture post's
|
|
`mvn dependency:tree` turns "the core has no Spring dependency" from a promise into
|
|
something Maven enforces.
|