← 목록으로

modeling/1.customer-account-domain.md

1. 고객 계정 관리 ERD

도메인 개요

고객/계정 관리는 멀티테넌트 시스템의 조직 경계, 고객 계정, 사용자 계정, 권한, API 인증을 관리하는 업무 도메인이다.

서브 도메인별 업무

• 테넌트 관리: 고객사 또는 사업부 단위의 운영 경계와 상태를 관리한다.
• 고객 계정 관리: 계약 및 과금 대상 고객 계정을 관리한다.
• 사용자 계정 관리: 운영자, 검토자, 고객 사용자 계정을 관리한다.
• 권한 관리: 역할 정의와 사용자-역할 매핑을 통해 접근 권한을 통제한다.
• API 인증 관리: 시스템 연동용 API 키 발급과 만료를 관리한다.

포함 테이블

• TENANT
• CUSTOMER
• USER_ACCOUNT
• ROLE
• USER_ROLE
• API_KEY

도메인 ERD (Mermaid)

erDiagram

TENANT {
  uuid tenant_id PK
  string tenant_name
  string tenant_type
  string status
  datetime created_at
}

CUSTOMER {
  uuid customer_id PK
  uuid tenant_id FK
  string customer_name
  string billing_type
  string status
  datetime created_at
}

USER_ACCOUNT {
  uuid user_id PK
  uuid tenant_id FK
  string email
  string display_name
  string status
  datetime created_at
}

ROLE {
  uuid role_id PK
  string role_name
  string description
}

USER_ROLE {
  uuid user_role_id PK
  uuid user_id FK
  uuid role_id FK
  datetime granted_at
}

API_KEY {
  uuid api_key_id PK
  uuid tenant_id FK
  string key_hash
  string status
  datetime issued_at
  datetime expires_at
}

TENANT ||--o{ CUSTOMER : has
TENANT ||--o{ USER_ACCOUNT : has
TENANT ||--o{ API_KEY : issues
USER_ACCOUNT ||--o{ USER_ROLE : granted
ROLE ||--o{ USER_ROLE : includes

외부 연계

• USER_ACCOUNT는 feasibility 실행, 리뷰, 스케줄 변경, 명령 승인 업무의 주체로 연결된다.
• CUSTOMER와 TENANT는 촬영 요청, 데이터 상품, 과금의 소유 주체로 연결된다.

테이블 정의서

TENANT

• 목적: 시스템의 최상위 멀티테넌트 조직 단위다.
• 업무 역할: 데이터 격리, 정책 적용, 과금 집계, 감사 범위의 기준이 된다.
• 주요 컬럼: tenant_id는 테넌트 식별자, tenant_name은 표시명, tenant_type은 조직 유형, status는 운영 상태, created_at은 생성 시각이다.

CUSTOMER

• 목적: 테넌트 산하의 실제 서비스 이용 고객 또는 계약 계정 단위다.
• 업무 역할: 촬영 요청 제출 주체와 과금 청구 대상을 분리해 관리한다.
• 주요 컬럼: customer_id는 고객 식별자, tenant_id는 소속 테넌트, customer_name은 고객명, billing_type은 과금 방식, status는 계정 상태, created_at은 생성 시각이다.

USER_ACCOUNT

• 목적: 시스템 사용자 계정 마스터다.
• 업무 역할: 평가 실행, 리뷰, 승인, 스케줄 조정, 명령 요청의 행위 주체를 표현한다.
• 주요 컬럼: user_id는 사용자 식별자, tenant_id는 소속 테넌트, email은 로그인 식별자, display_name은 표시명, status는 계정 상태, created_at은 생성 시각이다.

ROLE

• 목적: 권한 집합을 표현하는 롤 마스터다.
• 업무 역할: Planner, Reviewer, Operator, Admin 등 업무 역할 단위를 표준화한다.
• 주요 컬럼: role_id는 롤 식별자, role_name은 롤 이름, description은 역할 설명이다.

USER_ROLE

• 목적: 사용자와 롤 사이의 매핑을 저장한다.
• 업무 역할: 한 사용자가 여러 권한을 가질 수 있도록 하고, 권한 부여 시점을 추적한다.
• 주요 컬럼: user_role_id는 매핑 식별자, user_id는 사용자 FK, role_id는 롤 FK, granted_at은 권한 부여 시각이다.

API_KEY

• 목적: 외부 시스템 연동용 인증 키를 관리한다.
• 업무 역할: 시스템 간 호출의 인증 수단을 제공하고, 키 상태 및 만료를 통제한다.
• 주요 컬럼: api_key_id는 키 식별자, tenant_id는 발급 주체 테넌트, key_hash는 키 해시, status는 활성 상태, issued_at과 expires_at은 발급 및 만료 시각이다.

구현 권장사항

TENANT

• PK/FK: PK는 tenant_id. 다른 도메인 다수 테이블이 FK로 참조한다.
• NULL/필수: tenant_name, tenant_type, status, created_at은 NOT NULL 권장.
• 권장 인덱스: tenant_name 유니크 검토, status 보조 인덱스 권장.
• 예시 enum/status: tenant_type은 commercial, defense, internal. status는 active, suspended, terminated.

CUSTOMER

• PK/FK: PK는 customer_id, FK는 tenant_id -> TENANT.tenant_id.
• NULL/필수: tenant_id, customer_name, billing_type, status, created_at은 NOT NULL 권장.
• 권장 인덱스: (tenant_id, customer_name) 유니크 검토, (tenant_id, status) 인덱스 권장.
• 예시 enum/status: billing_type은 payg, subscription, contract. status는 active, inactive, closed.

USER_ACCOUNT

• PK/FK: PK는 user_id, FK는 tenant_id -> TENANT.tenant_id.
• NULL/필수: tenant_id, email, display_name, status, created_at은 NOT NULL 권장.
• 권장 인덱스: email 유니크, (tenant_id, status) 인덱스, (tenant_id, email) 보조 인덱스 권장.
• 예시 enum/status: status는 active, locked, disabled, pending.

ROLE

• PK/FK: PK는 role_id.
• NULL/필수: role_name은 NOT NULL, description은 선택 가능.
• 권장 인덱스: role_name 유니크 권장.
• 예시 enum/status: 예시 롤은 Planner, Reviewer, Operator, Admin, BillingManager.

USER_ROLE

• PK/FK: PK는 user_role_id, FK는 user_id -> USER_ACCOUNT.user_id, role_id -> ROLE.role_id.
• NULL/필수: user_id, role_id, granted_at은 NOT NULL 권장.
• 권장 인덱스: (user_id, role_id) 유니크, role_id 단독 인덱스 권장.
• 예시 enum/status: 별도 enum 없음. 중복 할당 방지를 위한 유니크 제약이 중요하다.

API_KEY

• PK/FK: PK는 api_key_id, FK는 tenant_id -> TENANT.tenant_id.
• NULL/필수: tenant_id, key_hash, status, issued_at은 NOT NULL, expires_at은 정책에 따라 nullable 가능.
• 권장 인덱스: key_hash 유니크, (tenant_id, status) 인덱스, expires_at 인덱스 권장.
• 예시 enum/status: status는 active, revoked, expired, rotating.

×