문서 목차
이 페이지에서목차

생성 배치 계약 — kernel + feature bundle

생성 전 프로젝트 루트에서 레이아웃을 먼저 확정한다. 정본은

생성 전 프로젝트 루트에서 레이아웃을 먼저 확정한다. 정본은 ADR v2 · D-097 AD-1·AD-2·AD-6·AD-9·AD-10과 co-bricks의 FeatureLayout.forProject다.

판정과 보존 (AD-6)#

  1. .cob/feature-layout.json이 있으면 schemaVersion: 1의 layout을 따른다. bundle·legacy 외 값, 잘못된 marker, marker와 반대인 --layout은 생성 전에 실패한다. 기존 marker 원문과 출처 필드를 보존한다. 생성 플래그로 이관하지 않는다.
  2. marker가 없으면 cob의 공용 판정을 그대로 따른다. 명시 요청이 없을 때 기존 legacy 트리가 있으면 legacy, 나머지 신규 프로젝트는 bundle이다. legacy 트리는 feature/{application,console,common,web,widgetbook}에 하위 디렉터리가 있고 해당 그룹 루트에 bundle.json이 없거나, backend 호스트의 lib/src/feature에 기능 디렉터리가 있는 경우다. 이름이 console인 번들을 legacy 그룹으로 오인하지 않는다.
  3. dry-run·조회는 marker를 쓰지 않는다. 실제 생성은 cob의 보존형 persist로 판정을 기록한다. 신규 scaffold 전에 판정을 고정해 커널의 기존 라우터를 legacy 증거로 다시 해석하지 않는다. kernel 스냅샷의 실제 origin ref와 generation-lock 출처도 보존한다.

bundle 출력 (AD-1·AD-10)#

역할패키지 루트pubspec 이름소스/테스트
app feature/<d>/app <d> lib/src/{domain,data,presentation,route,i18n} · test/
console feature/<d>/console console_<d> lib/src/{domain,data,presentation,route,i18n} · test/
server feature/<d>/server <d>_server lib/src/{endpoint,service,model,exception,validation,constant,helper} · test/unit/
client feature/<d>/client <d>_client Serverpod 생성 SDK
  • server의 config/generator.yaml은 type: module, client 경로는 ../client다.
  • feature/<d>/bundle.json은 조립 선언(schemaVersion, feature, requires, packages의 역할→경로, hostTests)이다. host-integration.json은 별도 호스트 결합 계약이다: 실제 패키지 이름의 예외, 포트 id, 식별자 도메인, legacy endpoint, donor의 extraClasses. 객체형 donor 입력을 읽더라도 새 출력은 두 파일로 나눈다. 필요한 역할만 생성한다.
  • 기능 문구는 feature/<d>/{app,console}/lib/src/i18n/에 두고 셸 locale 계약에 연결한다. 커널·호스트 공용 번역으로 옮기지 않는다. Widgetbook·골든도 기능 소유로 두고 앱은 조립한다.
  • manifest의 targets: [application]은 app 역할을 뜻한다. location=application도 app으로 매핑한다. console은 console 역할이며 common이라는 bundle 역할은 없다. 공용 코드는 기존 kernel/package 계약을 사용하거나 명시적인 기능 역할로 설계한다.

호스트 결합과 검증 (AD-2·AD-9·AD-11)#

  • backend/<project>_server는 실행·조립, 인증 provider, 교차 기능 업무, DB/HTTP/SDK 통합 테스트를 소유한다. 기능 소스는 모듈에 둔다. 모듈에서 호스트나 호스트 생성 protocol을 import하지 않는다.
  • 호스트 기능은 <Feature>HostBindings.bind(serverpod, …)와 forSession(session)의 세션 인지 포트로 받는다. 인스턴스별 바인딩이 없으면 실패하고, 생성 어댑터의 미구현 포트도 fail-closed로 실패한다. 성공 응답·샘플 데이터로 흉내 내지 않는다.
  • 순수 서비스·정책 단위 테스트는 feature/<d>/server/test/unit/, Flutter 단위·위젯·골든은 각 역할 패키지의 test/에 둔다. Session·실제 DB·withServerpod가 필요한 검증은 backend/<project>_server/test/integration/에 두고 bundle.json의 hostTests에 등재한다. Patrol은 실행 앱의 app/<app>/integration_test/에 둔다.
  • codegen은 requires DAG의 의존 모듈 → 해당 모듈 → 호스트 순서로 실행한다. 루트의 실제 bundle-aware 스크립트를 확인한다(예: tool/feature_codegen.dart). 모듈 migration을 만든 뒤 호스트 집계 migration을 공식 CLI로 생성·적용한다.
  • 신규 기본은 공식 Serverpod 4.0.3이다. 호스트·모듈·클라이언트·CLI 버전을 맞춘다. 4.1/databaseSync는 명시 opt-in이다. donor 버전으로 신규 기본을 올리지 않는다.
  • 통합 실행은 프로젝트의 격리 DB·세션별 포트/base-URL 계약을 따른다. 단위 테스트가 DB를 기동하지 않는다. donor 단위 테스트는 TZ=UTC에서도 통과해야 한다.

조건부 legacy 배치 — 공용 판정이 legacy일 때만#

marker.layout == legacy이거나 marker 없는 기존 트리가 위 cob 판정으로 legacy인 경우에만:

  • Flutter: feature/{application,common,console}/<package>/lib/src/와 같은 패키지의 test/.
  • 서버: backend/<project>_server/lib/src/feature/<d>/{endpoint,service,model,…}.
  • 기존 <project>_client·auth helper·workspace 스크립트와 배포 SDK 계약을 그대로 따른다.
  • raw mason make feature-*와 donor monorepo 스냅샷은 이 기존 프로젝트 경로에서만 안내한다. 신규 kernel 프로젝트는 cob generate/compose/apply로 bundle-aware 조립을 사용한다. donor UI는 kernel 계약으로 의존이 역전되기 전까지 복제하지 않는다(AD-7): server/client 역할과 compose UI를 사용하며 필요한 수용 호스트 포트를 구현한다.

검색어를 입력하면 문서를 찾습니다.

↑ ↓ 이동 · Enter 열기Esc 닫기