아키텍처 고르기

모델 하나를 세 가지로 읽습니다. elasticore { } 블록의 architecture 한 단어가 번들을 고르고, 모델은 그대로입니다.

build.gradle

elasticore {
    architecture = 'hexagonal'    // layered | ddd | hexagonal
    language     = 'java'         // java | kotlin
}

무엇을 주는가

	레이어드	DDD	헥사고날
Java 번들	jpa-springboot (-Pv3: jpa-springboot-v3)	ddd-springboot	hexagonal-springboot
Kotlin 번들	jpa-springboot-kt	ddd-springboot-kt	hexagonal-springboot-kt
엔티티, DTO, 매퍼, 리포지터리, 서비스, 컨트롤러	예	예	예
리포지터리·서비스·컨트롤러를 받는 엔티티	노출된 모든 엔티티	애그리거트 루트만	애그리거트 루트만
@access, @owner, @password, @login, @signin 강제	Java: 기본 2.x 호환 출력에는 없음(생성기가 경고), -Pv3·Kotlin: 예	예	예
생명주기(states:), @snapshot, @compute	아니오	예	예
불변식, 팩토리, 명세, 도메인 이벤트, commands:	아니오	예	예
잠긴 루트(XxxBase + 내 Xxx), @editable	아니오	예	예
다른 루트를 ID 로 참조(customerId)	아니오	예	예
도메인의 리포지터리 포트 + JPA 어댑터	아니오	예	예
인바운드 포트 <Entity>UseCase, 컨트롤러가 그것을 주입	아니오	아니오	예
problem+json 오류 응답(XxxApiErrors)	-Pv3·Kotlin	예	예

어떻게 고르나

• 새 프로젝트는 hexagonal 이나 ddd. DSL 이 말할 수 있는 모든 것(권한, 소유, 생명주기, 파생 값)을 다시 생성되는 코드에서 강제하므로, 규칙이 모든 진입점에서 지켜집니다. Pet Store, README 의 시작하기, 에이전트 키트의 레시피가 hexagonal 을 씁니다.
• hexagonal: 애플리케이션의 면을 인터페이스(OrderUseCase)로 두고, 패키지를 포트와 어댑터로 나누고 싶을 때 (application.port.in, adapter.in.web, infrastructure.persistence).
• ddd: 같은 도메인 모델에 컨트롤러가 응용 서비스를 직접 부르는 형태.
• layered: 3.0 으로 옮겨 오는 2.x 프로젝트. Java 에서는 규칙 엔진 위의 2.x 호환 출력입니다. 권한 검사와 problem+json 응답이 있는 정리된 출력은 -Pv3 를 더합니다.

패키지는 설정입니다

어느 파일이 어디에 놓이는지는 번들이 아니라 env.yml(namespace:)이 정합니다. namespace: base: com.acme.shop 은 헥사고날 패키지를 한 base 아래에 깔고, 함께 적은 키가 우선합니다. 번들은 무엇을 생성할지, 네임스페이스는 어디에 둘지를 정합니다.

나중에 바꾸기

architecture 를 바꾸는 것은 결정입니다. 루트마다 생성되는 파일(나뉜 루트, 유스케이스, ID 참조)이 달라지고, 이미 내 것이 된 한 번만 생성되는 파일은 다시 쓰지 않습니다. 생성기는 다시 쓸 수 없는 것을 알려 줍니다 - 예를 들어 생성자가 맞지 않게 된 확장 서비스는 constructor out of date with its core service - the generator now calls it with (...) 경고를 받습니다.