시그마스튜디오/에이전트-스킬

Principal Driven Domain Design

By Lex from SigmaStudioz.

비즈니스 소유권을 경로, 이름, 계약, 종속성에서 명확히 드러내세요. 올바른 동작, 읽기 쉬운 변경, 측정 가능한 성능, 경제적인 진화를 최적화하세요. 이 스킬을 요청된 변경에 적용하십시오. 프로젝트를 재설계할 권한을 부여하는 것은 아닙니다.

자동 실행

프로덕션 코드를 계획하거나 편집하기 전에 이 기준선을 적용하십시오. 스킬 호출, 트리거 구문, 아키텍처 요청을 기다리지 마십시오. 승인된 구현, 재사용, 간극 수정, 검증, 핸드오프를 단순히 제안하는 것이 아니라 코딩 작업의 일부로 수행하십시오. 검토 전용 또는 계획 전용 작업의 경우, 동일한 추론을 적용하되 코드는 편집하지 마십시오. 작업을 범위와 위험에 비례하게 유지하십시오. 자동 사용이 관련 없는 변경이나 위임을 승인하지는 않습니다.

에이전트 이식성 및 핸드오프

다음은 Markdown을 읽고 프로젝트를 검사할 수 있는 에이전트를 위한 도구 중립적 지침입니다. 사용 가능한 검색, 빌드, 테스트, 런타임 도구를 사용하십시오. 특정 벤더, 플러그인, CLI는 필요하지 않습니다. 호스트의 명령 계층 구조, 권한, 명시적 작업 범위를 존중하십시오. 이 스킬은 비활성화된 기능을 활성화하거나 배포, 게시, 파괴적 변경을 수행할 권한을 부여하지 않습니다.

위임이 이미 승인된 경우, 스킬의 접근 가능한 경로 또는 관련 지침, 소유 파일/모듈, 수용 조건, 추적 의무를 할당에 전달하십시오. 하위 에이전트가 상위 에이전트의 대화, 로드된 스킬, 전역 지침 파일을 상속받는다고 가정하지 마십시오. 각 워커로부터 증거와 해결되지 않은 경계를 요구하십시오. 워커 경계를 넘어 추적을 조정하십시오. 검증된 불변성을 위임하십시오. 제안된 알고리즘을 가정으로 표시하고 모순에 이의를 제기하십시오. 하위 에이전트가 스킬을 읽을 수 없는 경우, 허용된 컨텍스트 내에서 관련 내용을 제공하십시오. 이 섹션에서 핸드오프를 설명한다고 해서 에이전트를 생성하지 마십시오. 다른 워크플로우를 채택하기 전에, 사용자가 승인한 팀원 수와 역할을 기록하십시오. 모든 탐색, 구현, 검토 에이전트는 해당 예산을 소비합니다. 예산이 소진되면 후속 검토는 코디네이터에 머뭅니다. 선택적 워크플로우 스킬은 사용자의 제한을 확장할 수 없습니다. 작업 브리핑과 의사 코드를 제안으로 취급하십시오: 원래 계약과 비교하여 알고리즘을 독립적으로 확인하십시오. 결함 있는 계획을 구현 요구 사항으로 보존하지 말고 수정하십시오.

핸드오프 계약

승인된 모든 에이전트 할당 또는 재개 가능한 핸드오프는 다음을 식별해야 합니다:

필드	필수 컨텍스트
목표 및 제한	사용자 결과, 수용 조건, 승인된 작업, 제외 사항
위치	접근 가능한 작업공간 루트, 실제 브랜치/워크트리 또는 리비전, 관련 지침/스킬 경로
소유권	에이전트가 소유한 정확한 파일/모듈, 다른 활성 소유자 및 공유 인터페이스 종속성
아키텍처	도메인 소유자, 공개 진입점/계약, 중요한 호출자 및 소비자 경로
현재 상태	구현된 작업 대비 미완료 작업, 로컬 편집, 결정과 이유, 알려진 실패
증거	명령 및 결과, 추적 원장 경로/ID, 검증된 리비전, 사용 불가능한 환경
다음 작업	구체적인 다음 단계, 차단 요소, 필요한 입력, 예상 반환 형식

호스트는 위임 가드를 통해 이 계약을 강제할 수 있습니다. 선택적 Claude 가드는 이 기준선을 제공하고 기본 사용자 턴에서 명시적 숫자 에이전트 제한을 확인합니다(N teammates/agents/workers 사용). 기록이 없으면 코디네이터가 강제합니다. 도구를 부여하거나 의미론적 정확성을 보장하지 않습니다. 해당 가드가 설치된 경우, 할당 앞에 HANDOFF_JSON=와 goal, limits, workspace, revision, owns, interfaces, state, evidence, next, return, trace, checks, baseline을 포함한 JSON 객체를 접두사로 붙이십시오. return은 비어 있지 않은 paths, contracts, checks, gaps, remaining 지침을 포함한 객체여야 합니다. trace는 따라야 할 경로와 실패 사례를 명명합니다. checks는 실행할 검사 또는 실행 불가능한 이유를 명명합니다. baseline은 이 스킬의 접근 가능한 경로입니다. 이는 탐색 및 검토 할당에도 적용됩니다. 거부된 할당은 재시도 전에 수정되어야 합니다.

수신 에이전트의 호스트에서 실제 경로를 사용하십시오. 경로가 다르거나 접근 불가능한 경우 필요한 내용을 포함하십시오. 명령에 작업 디렉토리와 필수 비밀 아닌 구성 이름을 제공하십시오. 핸드오프 노트에 자격 증명이나 개인 런타임 페이로드를 절대 배치하지 마십시오. 브랜치 이름만으로는 하위 에이전트가 커밋되지 않은 작업을 볼 수 있다는 증거가 아닙니다. 체크아웃이 공유되는지 격리되는지 확인하십시오.

동시 작업의 경우, 중복 변경 전에 공개 계약과 파일 소유권에 동의하십시오. 에이전트에게 혼자가 아님을 알리십시오: 다른 사람의 편집을 보존하고 할당된 소유자를 통해 공유 파일을 조정하십시오. 통합을 주장하기 전에 격리된 변경을 리베이스하거나 조정하십시오. 작업을 조용히 폐기하지 마십시오. 반환 시 변경된 경로, 공개 계약 변경, 결과 포함 검사, 갭 ID/상태, 남은 작업을 보고하십시오. 코디네이터는 추적 원장을 조정하고 에이전트 간 경계와 영향을 받는 소비자를 검증합니다. 여러 워커 검사를 통과했다고 해서 작동하는 통합 워크플로우가 확립되는 것은 아닙니다.

중단 또는 컨텍스트 손실의 경우, 기존 작업/추적 레코드에 타임스탬프와 콘텐츠 리비전과 함께 핸드오프를 저장한 후 해당 레코드에 링크하십시오. 재개 시 작업 전에 체크아웃과 현재 diff를 검사하십시오. 오래된 가정을 재검증하십시오. 작업 진실의 두 번째 소스를 만들지 마십시오.

로컬 설치가 클라우드, 원격 호스트, 또는 관련 없는 에이전트 설치를 의미하지는 않습니다. 각 실행 호스트에서 발견을 설정하십시오. 관련 작업을 여기로 라우팅하려면 호스트 네이티브 전역 지침을 사용하십시오. 발견 또는 파일 접근이 불가능한 경우, 전역 강제를 주장하는 대신 해당 제한을 보고하십시오.

원칙 엔지니어링 계약

• 비즈니스 역량, 불변성, 사용자 워크플로우, 운영 제약 조건으로 시작하십시오.
• 도메인 내에서는 높은 응집력을, 도메인 간에는 낮은 결합도를 선호하십시오.
• 도메인별 코드를 소유자와 함께 배치하십시오. 해당 경계 내에서 코드를 기능별로 그룹화하십시오.
• 각 비즈니스 규칙과 권위 있는 쓰기 모델에 하나의 명확한 소유자를 지정하십시오.
• 다른 구현을 추가하기 전에 기존 구현을 재사용하십시오. 중복된 비즈니스 지식을 피하십시오.
• 입증된 요구 사항을 충족하고 예상 가능한 변경을 지원하는 가장 작은 아키텍처를 선택하십시오.
• 관찰, 가정, 결정, 증거를 분리하십시오. 요구 사항이나 벤치마크를 발명하지 마십시오.
• 동작 변경이 요청되지 않는 한 구조적 변경 중에 작동하는 공개 동작을 유지하십시오.
• 수정하는 경로와 필수 종속성을 개선하십시오. 관련 없는 코드를 작업에 포함시키지 마십시오.

1. 편집 전 컨텍스트 설정

해당되는 저장소 지침, 매니페스트, 패키지 내보내기, 진입점, 기존 도메인 모듈, 마이그레이션, 테스트, 관련 런타임 증거를 검사하십시오. 파일을 생성하기 전에 동등한 동작과 기존 공유 패키지를 검색하십시오. 저장소의 언어와 도구를 사용하십시오.

사용자 또는 이벤트 입력에서 권한 부여, 서비스, 도메인 규칙, 영속성, 다운스트림 효과, 반환 또는 표시된 상태까지 하나의 관련 워크플로우를 추적하십시오. 오류 경로를 포함하십시오. 실제 소비자와 작성자를 식별하십시오. 디렉토리 이름만으로는 소유권이 확립되지 않습니다.

중요한 아키텍처 작업의 경우, 간결한 결정 프레임을 설정하십시오:

질문	필수 답변
비즈니스 결과	어떤 사용자 워크플로우 또는 불변성이 변경됩니까?
소유권	어떤 경계 컨텍스트가 의미와 권위 있는 쓰기를 소유합니까?
소비자	어떤 앱, 작업, 모듈, 또는 외부 시스템이 기능을 필요로 합니까?
제약 조건	호환성, 데이터 볼륨, 지연 시간, 테넌시, 가용성, 비용, 배포?
현재 증거	관련 경로, 계약, 실패, 타이밍, 또는 쿼리 동작?
가장 작은 변경	무엇을 재사용할 수 있으며, 어떤 경계가 실제로 변경되어야 합니까?
완료	관찰 가능한 수용 조건과 적절한 검증?

올바른 작업을 차단하는 해결되지 않은 비즈니스 결정이 있는 경우에만 질문하십시오. 그렇지 않으면 가정을 명시하십시오.

2. 도메인 경계 정의

경계 컨텍스트는 일관된 비즈니스 어휘, 규칙, 모델을 소유합니다. 기능, 테이블, 화면, 프레임워크 계층, 배포, 또는 팀 이름이 자동으로 경계 컨텍스트가 되는 것은 아닙니다. billing, scheduling, playback, execution과 같은 비즈니스 역량 이름을 사용하십시오.

• 동일한 용어가 다른 의미, 불변성, 수명 주기, 또는 소유자를 가질 때 컨텍스트를 분리하십시오.
• 불변성이 하나의 원자적 작업에서 강제되어야 하는 경우 엔터티를 함께 유지하십시오.
• 과도하게 큰 집합체를 피하십시오: 실제 원자적 불변성과 공유 트랜잭션 대신 명시적 일관성, 오케스트레이션, 또는 보상이 필요한 컨텍스트 간 워크플로우를 구별하십시오.
• 핵심 비즈니스 차별화를 지원 및 상용 역량과 구별하십시오.
• 복잡성이나 비즈니스 가치가 보증하는 곳에 모델링 노력을 투자하십시오. 단순한 CRUD는 단순하게 유지하십시오.
• 중요한 컨텍스트 경계에서 업스트림/다운스트림 소유권과 변환을 기록하십시오.
• 다른 컨텍스트를 공개 API, 포트, 또는 계약을 통해 소비하십시오. 내부를 가져오지 마십시오.
• 경계에서 외부/공급자 모델을 변환하십시오. 비즈니스 규칙으로 누출하지 마십시오.
• 독립적인 배포, 확장, 장애 격리, 또는 소유권이 서비스 분할을 정당화할 때까지 모듈식 모놀리스를 선호하십시오. 모노레포가 마이크로서비스를 의미하지는 않습니다.

변경이 여러 도메인에 걸쳐 있는 경우, 오케스트레이션 사용 사례와 각 도메인의 책임을 식별하십시오. 오케스트레이션을 워크플로우 소유자와 함께 배치하십시오. 전역 헬퍼나 UI 컴포넌트에 두지 마십시오.

3. 도메인별, 기능별 구조화

먼저 소유 범위를 선택한 다음 기능 범주를 선택하십시오. 해당 범위 내에서:

범주	책임
model/	엔터티, 값 객체, 불변성, 정책, 도메인 이벤트
services/	명명된 애플리케이션 사용 사례 및 오케스트레이션
ports/	영속성, 클록, ID, 큐, 공급자를 위한 인터페이스
adapters/	구체적인 데이터베이스, 전송, 공급자, 또는 플랫폼 구현
contracts/	공개 DTO, 이벤트 스키마, 검증, 호환성 계약
components/, hooks/	도메인이 프론트엔드를 소유하는 경우 도메인 UI 및 UI 동작
shared/	해당 범위 내 소비자를 위한 재사용 가능한 코드
tests/ 또는 공동 배치된 테스트	저장소 규칙을 사용한 동작 및 경계 검증

서비스 구현은 해당 소유 계층의 services/에 속합니다. 여러 엔터티에 걸친 규칙에 도메인 서비스가 필요한 경우 model/services/에 배치하십시오. 오케스트레이션은 도메인의 기본 services/에 머뭅니다. 공급자 서비스는 유용한 경우 adapters/services/에 있을 수 있습니다.

하나의 앱의 경우, 필요에 따라 src/domains/<domain>/{model,services,ports,adapters,contracts,shared}를 사용하고, 공개 진입점, 얇은 프레임워크 라우트, 구성 루트를 사용하십시오. 도메인 중립적인 프리미티브는 src/shared/ 아래에 두십시오. 실제 코드가 포함된 디렉토리만 생성하십시오.

모노레포 예시: 기존 패키지 규칙과 명시적 내보내기를 존중하십시오.

apps/
  web/                           # 앱 구성 및 프레젠테이션
  api/                           # 얇은 전송 진입점
  worker/                        # 작업 등록 및 구성
packages/
  billing/                       # 소유된 워크스페이스 패키지
    package.json                 # 공개 내보내기 및 런타임 호환성
    src/
      services/                  # API/워커가 공유하는 사용 사례
      shared/                    # Billing-로컬 재사용
      index.ts                   # 명시적 공개 퍼사드
  shared/
    contracts/                   # 도메인 중립 워크스페이스 패키지
    ui/                          # 호환 가능한 프론트엔드 소비자

실제 패키지를 워크스페이스에 등록하십시오. 경로만으로는 가져올 수 없습니다. 다국어 워크스페이스에서는 표준 스키마에서 호환 가능한 라이브러리나 생성된 클라이언트를 노출하십시오. 호환되지 않는 런타임 간에 코드를 가져오려고 시도하지 마십시오.

배치 규칙

1. 한 명의 소비자와 도메인별 의미: 해당 도메인에 유지하십시오.
2. 하나의 도메인 내 여러 소비자: 해당 도메인의 services/ 또는 shared/를 사용하십시오.
3. 여러 호환 앱이 재사용 가능한 도메인 코드를 필요로 함: 워크스페이스 도메인 패키지에 배치하십시오. 권한 있는 서버 동작은 승인된 API 또는 클라이언트 계약 뒤에 서버 측에 남습니다.
4. 여러 도메인이 동일한 도메인 중립 프리미티브를 필요로 함: 범위가 지정된 shared/ 코드를 사용하십시오.
5. 소비자가 다른 비즈니스 의미를 필요로 함: 별도의 모델을 유지하고 명시적으로 변환하십시오.
6. 도메인 간 워크플로우: 소유 애플리케이션 서비스와 공개 도메인 계약을 사용하십시오.
7. 경로, 화면, 컨트롤러, 작업: 서비스에 규칙을 위임하십시오. 전송 관련 사항을 로컬로 유지하십시오.

가져오기를 편리하게 하기 위해 기능을 여러 앱에 복사하지 마십시오. 한 앱을 다른 앱의 라이브러리로 만들지 마십시오. 재사용 가능한 소유권을 두 앱이 모두 의존할 수 있는 패키지로 아래로 이동하십시오. 필수 프레임워크 디렉토리를 유지하십시오. 프레임워크와 싸우지 말고 도메인 구조로 라우팅하십시오. 언어 표준 패키징 및 유효한 기존 아키텍처를 존중하십시오.

4. 종속성 방향 강제

진입점 -> 공개 애플리케이션 서비스 -> 모델 + 포트
어댑터 -> 포트 + 모델
부트스트랩 -> 서비스 + 어댑터             # 구체적인 구현 연결
도메인 패키지 -> 도메인 중립 공유 패키지

• 모델은 HTTP, UI 프레임워크, 데이터베이스, 큐, 공급자 SDK에 의존하지 않습니다.
• 서비스는 명시적 종속성을 통해 사용 사례를 오케스트레이션합니다. 어댑터는 포트를 구현합니다.
• 공유 패키지는 앱 또는 도메인 내부를 가져오지 않습니다. 순환 종속성을 피하십시오.
• 도메인 간 호출은 공개 계약을 사용합니다. 동기 호출 주기와 잡담 체인을 피하십시오.
• 의도적인 진입점을 내보내십시오. 기존 패키지, 린트, 또는 빌드 도구를 사용하여 깊은 가져오기를 차단하십시오.
• 브라우저 안전 계약을 서버 전용 구현 및 권한 있는 종속성과 분리하십시오.
• 권한 있는 SDK, 데이터베이스 클라이언트, 비밀, 파일 시스템 코드를 클라이언트 종속성 그래프 밖에 유지하십시오.
• 공급자 SDK는 애플리케이션 어댑터 레이어에서 실행되어야 하며 모델에 직접 포함되지 않아야 합니다.
• 데이터베이스 트랜잭션, 캐시, 검색 인덱스, 분산 잠금은 해당 경계 컨텍스트의 서비스 또는 리포지토리 구현에 속합니다. 특별한 이유 없이 비즈니스 규칙 계층으로 누출하지 마십시오.
• 교차 도메인 워크플로우에서 공유 트랜잭션은 경계 컨텍스트가 동일한 데이터 저장소와 호환 가능한 일관성 모델을 공유하는 경우에만 허용됩니다. 그렇지 않으면 최종 일관성, 보상 트랜잭션, 또는 saga를 사용하십시오.

5. 서비스 레이어링

레이어	구성
엔터프라이즈 비즈니스 규칙	도메인 모델(엔터티, 값 객체, 불변성)
애플리케이션 비즈니스 규칙	애플리케이션 서비스(사용 사례 오케스트레이션)
인터페이스 어댑터	컨트롤러, 프레젠터, 게이트웨이, 리포지토리
인프라	데이터베이스, 메시징, 파일 시스템, 디바이스

종속성은 안쪽으로 향합니다. 외부 레이어는 인접한 내부 레이어에만 의존합니다. 핵심 도메인 레이어는 프레임워크, 데이터베이스, 전송 계층에서 완전히 분리되어야 합니다. 종속성 주입을 사용하여 인프라 세부 사항을 애플리케이션 서비스에 연결하십시오.

6. 테스트 전략

행동 기반 테스트를 선호하고 구현 세부 사항에 밀접하게 결합된 테스트를 피하십시오.

• 도메인 모델: 단위 테스트는 엔터티, 값 객체, 도메인 서비스를 통해 비즈니스 규칙을 검증합니다. 모의 객체 없음.
• 애플리케이션 서비스: 통합 테스트는 저장소 및 외부 시스템과의 상호 작용을 검증합니다. 중요한 경계에 대한 모의 객체.
• 어댑터: 프로토콜 호환성 및 오류 처리를 확인하기 위한 계약 테스트.
• 엔드-투-엔드: 중요 사용자 워크플로우를 위한 소수의 스모크 테스트.
• 테스트는 프로덕션 코드와 동일한 디렉토리 구조를 미러링해야 합니다.
• 프로덕션 동작을 문서화하는 테스트를 작성하십시오. 임의의 적용 범위 목표가 아닙니다.
• 외부 시스템의 복잡한 내부를 모의하지 마십시오. 페이크 또는 테스트 컨테이너를 선호하십시오.

7. 변경 관리

• 중요한 공개 API를 변경하기 전에 더 이상 사용되지 않음(deprecation) 주기를 도입하십시오.
• 커밋 또는 PR은 논리적으로 원자적인 단일 변경을 캡슐화해야 합니다.
• 변경 로그를 유지하고 호환되지 않는 변경을 명확하게 표시하십시오.
• 아키텍처 결정 기록(ADR)을 사용하여 중요한 설계 선택을 문서화하십시오.
• 작업 시작 전에 리팩토링과 기능 추가를 명확하게 구분하십시오.
• 기술 부채를 작업 항목으로 추적하십시오. 코드 검토에서만 수정하지 마십시오.

8. 문서

• 문서는 코드와 가까이 유지하고, 가능하면 코드와 같은 저장소에 두십시오.
• 진입점 README는 시작하는 방법을 설명합니다.
• ADR은 중요한 아키텍처 결정과 그 맥락을 기록합니다.
• 계약은 개방형 API 사양, 프로토콜 버퍼, 또는 유사한 기계 판독 가능 형식으로 문서화됩니다.
• 공유 라이브러리 README는 가져오기 지침, 호환성 요구 사항, 변경 로그를 제공합니다.
• 기록이 아닌 지침을 문서화하십시오. 즉각적으로 유용한 것에 집중하십시오.

9. 모니터링 및 관찰 가능성

• 비즈니스 및 시스템 메트릭 모두에 대한 구조화된 로깅을 구현하십시오.
• 중요한 비즈니스 이벤트를 추적하기 위한 분산 추적을 사용하십시오.
• 핵심 성능 지표에 대한 대시보드를 제공하십시오.
• 중요한 오류 및 성능 저하에 대한 경고를 구성하십시오.
• 관찰 가능성을 위한 추가 코드가 아닌 기존 인프라(예: OpenTelemetry)를 활용하려고 노력하십시오.
• 로깅, 메트릭, 추적 구성을 인프라 코드의 일부로 유지하십시오.

10. 보안

• 입력 검증 및 살균을 어댑터 레이어에서 수행하십시오.
• 사용자 입력을 도메인 모델에 직접 신뢰하지 마십시오. 전송 및 저장 시 검증하십시오.
• 종속성에 최소 권한 원칙을 적용하십시오.
• 비밀을 코드베이스에 저장하지 마십시오. 환경 변수 또는 비밀 관리자를 사용하십시오.
• SQL 주입, XSS, CSRF와 같은 일반적인 취약점을 방지하기 위해 프레임워크 보안 기능을 사용하십시오.
• 보안 관련 변경 사항을 정기적으로 감사하고 종속성을 최신 상태로 유지하십시오.

11. 성능

• 프로파일링 없이 최적화하지 마십시오. 먼저 병목 현상을 식별하십시오.
• 데이터베이스 쿼리에 대한 지연 시간 및 처리량 목표를 정의하십시오.
• 읽기 집약적인 워크로드에 캐싱 전략을 사용하십시오.
• 비동기 처리를 위해 큐를 사용하고 동기식 장기 실행 작업을 피하십시오.
• 데이터베이스 인덱스 결정을 쿼리 패턴 및 프로파일링 데이터에 기반하십시오.
• 부하 테스트는 프로덕션 트래픽 패턴을 모방해야 합니다.

12. 배포

• 배포 파이프라인을 코드로 정의하십시오.
• 환경 구성을 코드베이스 외부에서 관리하십시오.
• 블루-그린 또는 카나리아 배포 전략을 선호하십시오.
• 배포 전에 데이터베이스 마이그레이션을 테스트하십시오.
• 롤백 계획을 세우고 연습하십시오.
• 배포를 기록하고 관련 변경 로그에 연결하십시오.

부록 A: 용어집

• 경계 컨텍스트: 일관된 비즈니스 어휘, 규칙, 모델을 소유하는 명시적 경계.
• 집합체: 하나의 단위로 처리되는 도메인 개체의 클러스터, 루트 엔터티에 의해 액세스됨.
• 도메인 이벤트: 도메인 내에서 발생한 중요한 사건.
• 값 객체: ID 없이 속성으로 정의된 개체.
• 엔터티: 연속성과 ID로 정의된 개체.
• 저장소: 집합체 컬렉션과 유사한 인터페이스를 제공하는 메커니즘.
• 서비스: 상태를 저장하지 않고 동작을 캡슐화하는 작업.

부록 B: 일반적인 안티 패턴

• 신 서비스: 도메인 논리를 모르는 전역 유틸리티 클래스.
• 마법 같은 문자열: 명명된 상수나 열거형 대신 사용되는 하드코딩된 값.
• 단일 책임 위반: 여러 이유로 변경되는 클래스.
• 순환 종속성: 서로 의존하는 모듈.
• 뚱뚱한 컨트롤러: UI 레이어의 비즈니스 규칙.
• 데이터베이스 중심 설계: 도메인 모델보다 데이터베이스 스키마에 집중.
• 조기 추상화: 필요하기 전에 인터페이스 또는 일반화 도입.

부록 C: 권장 도구

• 의존성 검사: 기존 빌드 시스템 또는 archunit와 같은 전용 도구.
• 코드 분석: SonarQube, ESLint, Pylint, 또는 유사.
• 계약 테스트: Pact 또는 Spring Cloud Contract.
• 아키텍처 결정 기록: adr-tools 또는 유사.