Files

2.5 KiB

Repository Guidelines

Project Structure & Module Organization

This repository is a multi-module Maven project (pom.xml) targeting Java 21.

  • ljwx-platform-app: Spring Boot entrypoint, controllers, facade/appservice/domain/infra layers, integration tests.
  • ljwx-platform-core: shared result models, constants, and error codes.
  • ljwx-platform-web: web filters and global exception handling.
  • ljwx-platform-security: JWT, auth, and tenant context/isolation support.
  • ljwx-platform-data: datasource/MyBatis/Flyway configuration and migrations (src/main/resources/db/migration).
  • contracts/: OpenAPI and security policy contracts.
  • docs/: architecture, requirements, design, contracts, dev guide, runbook, ADRs.
  • scripts/gates: CI/local quality gates.

Build, Test, and Development Commands

  • ./mvnw -q -DskipTests package: compile all modules quickly.
  • ./mvnw -q test: run unit tests (*Test.java).
  • ./mvnw -q -PIT verify: run integration tests (*IT.java, requires Docker/Testcontainers).
  • ./mvnw -pl ljwx-platform-app -am spring-boot:run: run the app locally.
  • bash scripts/gates/gate-all.sh: run manifest, PR, tests, contract, and NFR gates.

Coding Style & Naming Conventions

Follow layer dependency direction strictly: controller -> facade -> appservice -> domain <- infra.

  • Do not call MyBatis mapper directly outside infra.persistence.repository.
  • Keep domain model classes framework-agnostic.
  • Package root pattern: com.ljwx.platform.{module}.
  • Migration naming: V{3-digit}__description.sql (example: V003__add_user_index.sql).
  • Use standard Java formatting (4-space indentation, clear method/class names). No formatter is enforced in CI, so keep style consistent with nearby code.

Testing Guidelines

  • Unit tests: *Test.java (Surefire).
  • Integration tests: *IT.java (Failsafe under profile IT).
  • Integration tests should reuse BaseIT in ljwx-platform-app/src/test/java/.../BaseIT.java where applicable.
  • Validate Docker is available before running ITs: docker info.

Commit & Pull Request Guidelines

There is no stable local commit history yet, so use Conventional Commits (for example, feat(auth): add refresh token endpoint) until a project-specific pattern is established.

Use .gitea/pull_request_template.md and complete all required sections:

  • 需求号
  • 契约变更说明
  • 控制面影响
  • 测试证据

PRs should include linked requirement docs (for example, docs/01-requirements/R-001.md) and clear test evidence (./mvnw test, ./mvnw -PIT verify, or manual verification notes).