기본 규칙 끄기와 번들 고르기

팀 규칙은 더하기만 하는 것이 아닙니다. ElastiCORE 가 만드는 것 중 팀에 맞지 않는 것을 빼는 방법이 세 가지 있습니다.

하고 싶은 것	방법
기본 규칙 하나를 통째로 끄기 (예: 모든 @Comment)	suppress: [규칙 id]
한 파일 종류를 아예 만들지 않기	그 target 의 규칙을 모두 suppress, 또는 팀 규칙에서 ctx(e).dontMake()
규칙이 하는 일 중 하나만 빼기 (예: @DynamicUpdate 만)	팀 규칙에서 removeClassAnnotation, field(f).removeAnnotation, removeField
한 도메인만 다른 번들로	env.yml 의 publisher.rules

1. 규칙 id 찾기

./gradlew elcore3 -PlistRules

파일을 만들지 않고, 도메인마다 지금 도는 규칙을 파일 종류(target)별로 실행 순서대로 보여 줍니다.

  entity
        5 head  v3-class-annotations                 JpaEntityAnnotationRules
        5 field jpa-field-desc                       JpaEntityBaseRules
        …
  apiErrors
       10 once  spring-api-errors                    ApiErrorRules

칸	뜻
entity, apiErrors …	target - 그 규칙이 쓰는 파일 종류. 생성 로그 각 줄의 첫 단어와 같음
5, 10	order
head / field / tail / once	단계. once 는 도메인·enum·port 단위
spring-api-errors	규칙 id - suppress 에 쓰는 이름
ApiErrorRules	규칙이 든 클래스

2. suppress - 규칙 끄기

한 도메인에서만:

blueprint/petstore/env.yml

elasticore:
  config:
    publisher:
      suppress: [jpa-comment]     # 엔티티 필드의 @Comment 를 더 이상 붙이지 않음

모든 도메인에서 (각 env.yml 의 suppress 와 합쳐짐):

build.gradle

elasticore {
    suppress = ['jpa-comment']
}

• suppress 는 누적됩니다. 빌드에 적은 것과 도메인에 적은 것이 모두 꺼집니다.
• 한 파일 종류의 규칙을 모두 끄면 그 파일은 만들어지지 않습니다 (생성 로그에 SKIP(dontMake)).
• 이미 만들어진 개발자 파일(컨트롤러, 오류 처리기 등)은 지워지지 않습니다. 필요 없으면 직접 지우세요.

끄면 동작이 바뀌는 것

예를 들어 회사 공통 @RestControllerAdvice 가 있어 spring-api-errors(도메인마다 생기는 XxxApiErrors)를 끄면, 그 파일이 정하던 응답 - 없는 대상 404, 중복·상태 충돌 409, 업무 규칙 위반 422 - 을 회사 처리기가 정해야 합니다(없으면 500). 컨트롤러에 닿기 전의 거절(JSON 이 아닌 본문, 타입이 틀린 값)도 함께 빠지므로 회사 처리기에 @Import(io.elasticore.springboot3.validation.RequestShapeErrors.class) 를 붙이세요.

끄면 안 되는 것

파일의 뼈대를 채우는 규칙 - ${packageName}, ${className}, ${importList} 같은 빈칸을 채우는 *-vars, *-file 규칙 (v3-file-vars, v3-dto-file, controller-vars …, -PlistRules 에서 보통 90 tail) - 을 일부만 끄면 빈칸이 비어 파일이 깨집니다. suppress 는 무언가를 "더 붙이는" 규칙을 끄거나, 한 파일의 규칙을 모두 꺼서 통째로 뺄 때 씁니다.

3. 규칙이 하는 일 중 하나만 빼기

suppress 는 규칙 단위입니다. v3-class-annotations 는 @Entity, @Table, @DynamicUpdate … 를 함께 붙이므로 끌 수 없습니다. 이럴 때는 팀 규칙이 뒤에서 하나만 지웁니다. 팀 규칙은 기본 규칙이 끝난 뒤에 돌기 때문에 뺀 것이 다시 붙지 않습니다.

    /** Takes one annotation the built-in rules put on every entity back off. */
    @Rule("ps-no-dynamic-update")
    void noDynamicUpdate(EntitySpec e) {
        ctx(e).removeClassAnnotation("org.hibernate.annotations.DynamicUpdate");
    }

같은 방식: ctx(e).field(f).removeAnnotation("…"), ctx(e).removeField(f), ctx(e).dontMake(). (@DynamicUpdate 는 DSL 로도 뺄 수 있습니다: 엔티티 meta 에 @dynamicupdate(false). 한 엔티티만이라면 DSL 로, 모든 엔티티에서라면 규칙으로 하세요.)

4. 도메인마다 번들 고르기 - publisher.rules

대부분의 프로젝트는 필요 없습니다. build.gradle 의 architecture·language 가 번들을 고르고, rules = [...] 가 그 뒤에 팀 규칙을 더합니다. 한 도메인만 다르게 생성할 때 env.yml 에 적습니다.

blueprint/legacy/env.yml

elasticore:
  config:
    publisher:
      rules: [jpa-springboot-v3, com.example.rules.PetstoreRules]

	build.gradle 의 rules	env.yml 의 publisher.rules
번들	그대로 두고 뒤에 더함	대체 - 번들 이름도 적어야 함
범위	모든 도메인	그 도메인만
Kotlin	언어에 맞는 번들이 자동	-kt 번들을 직접 적거나 publisher.rules.kt
TypeScript	영향 없음	publisher.rules.ts 따로

이름은 번들(hexagonal-springboot), 규칙 집합(ossie-export), 또는 CodeRules 의 전체 클래스 이름 셋 중 하나입니다. 도메인의 publisher.rules 는 그 도메인의 번들을 대체하고, 빌드의 rules = [...] 는 어느 쪽이든 그 뒤에 더해집니다 - 위 예에서 PetstoreRules 를 빌드에도 적었다면 env.yml 에서는 빼도 됩니다. 번들 목록은 규칙 엔진에 있습니다.

env.yml 에 rules: 를 적었더니 헥사고날 파일이 사라졌다면, 번들 이름을 빠뜨린 것입니다. 모든 도메인에 적용할 팀 규칙은 빌드의 rules 에 적으세요 - 틀릴 곳이 없습니다.