Nested module discovery
The model captures 31 source-bearing modules across nested Maven reactor folders.
Repository validation
Spring Modulith
A Java and Spring multi-module repository with core libraries, event integrations, observability modules, examples, and integration tests.
Independent analysis of a public repository. This project is not affiliated with or endorsed by ArchPilot. Product and project names are used only for identification.
Spring is a trademark of Broadcom Inc. and/or its subsidiaries.
See something inaccurate? Contact us.What ArchPilot found
31 components, 51 relationships, no errors.
ArchPilot modeled Spring Modulith as a 31-component Maven reactor covering core libraries, event integrations, observability modules, examples, and integration-test modules.
The run shows nested module discovery, dependency hubs in shared event infrastructure, and scope-dependent event findings where examples and integration-test modules are intentionally governed.
Source-backed architecture units
Mapped module dependencies
Blocking validation findings
Items for review, not confirmed defects
Why it is useful
From repository shape to reviewable architecture signals.
The point is not to score open-source projects against each other. The point is to show how local validation turns repository structure into a model teams can inspect and govern.
Dependency hotspots
Shared event API and core modules stand out as dependency hubs.
Scoped examples
Findings in example and integration-test modules are visible and clearly scope-dependent.
Clean setup
No error-level findings and full readiness make the result easy to reproduce and inspect.
Findings
What deserves attention
13 normalized finding clusters
Findings below are grouped into areas so readers can see what is deterministic architecture evidence, what is a review signal, and what depends on governance scope.
Dependency hubs
Shared API and event modules have high inbound dependency counts.
Published events
Example and integration-test modules publish events without statically visible handlers.
Repository responsibilities
Repository methods such as findByStatus and getStatus contain behavior worth human review.
Decision context
The generated governance model expects ADR context for dependency governance.
Confirmed architecture evidence
Event modules form visible dependency hubs
Several event API and core modules have high inbound dependency counts, matching their role as shared event infrastructure.
Review signal
Repository methods contain status-oriented behavior
Repository implementations include methods such as findByStatus and getStatus. ArchPilot presents these as review signals, not confirmed design defects.
Scope-dependent observation
Examples publish events without static handler evidence
These events are published from governed example and integration-test modules. The event evidence is real, but its significance depends on whether those non-production modules are intentionally included in the governance scope.
How to interpret this validation
- Generated configuration governs examples and integration-test modules, which affects event finding interpretation.
- Warnings are not confirmed project defects. Many are heuristic or scope-dependent review signals.
- Scores describe conformance to the generated model and supported rules, not a ranking against other projects.
- This is independent analysis of a public repository, not maintainer endorsement.
Reproduce and verify
Run from commit 758a425c87b2 with ArchPilot 0.2.5.
Exact CLI commands
npx --yes @archpilotlabs/[email protected] init --yes
npx --yes @archpilotlabs/[email protected] validate --json
npx --yes @archpilotlabs/[email protected] map --json
npx --yes @archpilotlabs/[email protected] report --jsonRepository provenance
- Repository
- spring-projects/spring-modulith
- Branch
- main
- Commit date
- 2026-08-13T11:49:28+02:00
- Validation date
- Aug 21, 2026
Package and configuration proof
- Package
@archpilotlabs/archpilot@0.2.5- Tarball
- npm package tarball
- Integrity
sha512-EMyKdhnEREogSSqjfWzQzUzSzftERVqyUtSfpoEQEe3TaQfo2qG1AFvo5pwxmz4RgJ8yLqy5j4MX1fD13Nnzwg==- Config hash
39CC6BD1476F2F9DC62BF2A1A4070C63EC49A6873347A84A8F1324CEF56979D4
Artifact hashes
- architecture.json
39CC6BD1476F2F9DC62BF2A1A4070C63EC49A6873347A84A8F1324CEF56979D4- validation-status.json
AE1A187AF5A2C2EFA7BDA4F95DE37C3BAB8C803572670A4A54DDA1E536391D21- architecture-map.json
32C0CE5836467DCFAAE1C332DEE3711DE5B87F15A173527D1A5DF79401CCC87B- architecture-review-report.json
37FE3F2AD89EED80857432EB70C76F171EB3CD0B282B2D3DB7C593A4D96576D2
Try it locally
Run the same workflow on your repository.
The extension and CLI validate architecture locally. ArchPilot Cloud brings those results together for shared history, policy workflows, cross-repository intelligence, and organization-wide governance.