structure-codebase

Group files by capability, feature, or use case so code that changes together stays together, and expose a small explicit public API per module. Avoid global buckets like controllers, services, or utils that scatter one behavior across the tree.

Use a visible hexagon only when the project explicitly adopts ports and adapters and has meaningful application policy that must run without real external systems. Simple CRUD, provider wrappers, and small packages should use honest shallow or feature-first structures instead.

No, bounded contexts and hexagonal architecture are independent axes. DDD contexts define language and model authority, while a hexagon defines a technology test wall; a project can use either one without the other.

Validate both source imports and package.json dependencies using restricted imports, architecture tests, explicit public exports, and workspace discovery checks. For large workspaces, derive rules from package roles or a small registry rather than hand-maintained allowlists.

Frontend structure classifies route ownership, product-feature cohesion, UI reuse level, state and data ownership, and runtime boundaries independently. Do not project backend hexagon or ports vocabulary onto client code unless the frontend explicitly earns that boundary.

Separate semantic changes from mechanical moves: record the decision, protect behavior with characterization tests, prepare enforcement, decompose god files, invert leaked dependencies, then reparent packages one capability at a time. Never combine mass moves with behavior changes in one step.