Skip to content

Latest commit

 

History

History
398 lines (327 loc) · 10.1 KB

README.md

File metadata and controls

398 lines (327 loc) · 10.1 KB
Raw

블꾸

커스텀 극대화 블로그

blccu.com

Tech Stack

  • Nest.js
  • mysql/typeORM

ERD

erDiagram
    notification {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string type
        bool is_checked
        int article_id FK
        int user_id FK
        int target_user_id FK
    }
    follow {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        int to_user_id FK
        int from_user_id FK
    }
    agreement {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string agreement_type
        bool is_agreed
        int user_id FK
    }
    feedback {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string content
        string type
        int user_id FK
    }
    article {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        int article_category_id FK
        int article_background_id FK
        string html_title
        bool is_published
        int like_count
        int view_count
        int comment_count
        int report_count
        bool allow_comment
        string scope
        string content
        string main_description
        string image_url
        string main_image_url
        int user_id FK
    }
    article_category {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string name
        int user_id FK
    }
    article_background {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string image_url
    }
    user {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string handle
        string current_refresh_token
        bool is_admin
        int following_count
        int follower_count
        string username
        string description
        string profile_image
        string background_image
    }
    comment {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        int article_id FK
        int content
        int report_count
        int parent_id
        int user_id FK
    }
    report {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string content
        string type
        string target
        int article_id FK
        int comment_id FK
        int user_id FK
        int target_user_id FK
    }
    like {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        int article_id FK
        int user_id FK
    }
    sticker_block {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        int sticker_id FK
        int article_id FK
        float scale
        float angle
        float pos_x
        float pos_y
        float z_index
        int client_id
    }
    sticker {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string image_url
        bool is_default
        bool is_reusable
        int user_id FK
    }
    sticker_category {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string name
    }
    sticker_category_mapper {
        int sticker_id FK
        int sticker_category_id FK
        datetime date_created
        datetime date_updated
        datetime date_deleted
    }
    announcement {
        int id PK
        datetime date_created
        datetime date_updated
        datetime date_deleted
        string title
        string content
    }

    notification ||--o{ article : relates
    notification ||--o{ user : notifies
    notification ||--o{ user : targets
    follow ||--o{ user : follows
    follow ||--o{ user : followed_by
    agreement ||--o{ user : belongs_to
    feedback ||--o{ user : given_by
    article ||--o{ article_category : belongs_to
    article ||--o{ article_background : has_background
    article ||--o{ user : written_by
    comment ||--o{ article : related_to
    comment ||--o{ user : authored_by
    report ||--o{ article : reports
    report ||--o{ comment : reports
    report ||--o{ user : filed_by
    report ||--o{ user : targets
    like ||--o{ article : liked
    like ||--o{ user : liked_by
    sticker_block ||--o{ sticker : contains
    sticker_block ||--o{ article : placed_on
    sticker ||--o{ user : owned_by
    sticker_category_mapper ||--o{ sticker : maps_to
    sticker_category_mapper ||--o{ sticker_category : categorized_as
Loading

네이밍 룰의 우선사항

엔티티 중심의 클래스 작명: {Entity}{Action}{Purpose}{Layer}

UserCreateResponseDto, ArticlesCreateService

Layer 중심의 인스턴스 작명: {Layer}_{Entity}{Action}{Purpose}

svc_usersCreate, dto_userCreateResponse

선택적 도메인과 접두사 활용해 지역변수 및 필드 작명: ({prefix})({Domain}){Name}

isPubluished, userId, articleId

DTO 네이밍 룰

Common DTO: 모든 계층에서 공통으로 사용할 수 있는 기본 DTO.

{Entity}Dto

Request DTO: 클라이언트 -> 컨트롤러 간의 데이터 전송.

{Entity}{Action}RequestDto

Response DTO: 컨트롤러 -> 클라이언트 간의 데이터 전송. 혹은 공통된 response일 때 사용.

{Entity}{Action}ResponseDto

Service Output DTO: 서비스 -> 컨트롤러 간의 별도의 데이터 전송.

{Entity}{Action}SvcOutputDto

Repository Output DTO: 레포지토리 -> 서비스 간의 별도의 데이터 전송.

{Entity}{Action}RepoOutputDto

Service Interface: 컨트롤러 -> 서비스 간의 데이터 전송.

I{Entity}{Layer}{Action}

Repository Interface: 서비스 -> 레포지토리 간의 데이터 전송.

I{Entity}{Layer}{Action}

메서드 네이밍 룰

  • 컨트롤러 메서드: HTTP 요청 중점 네이밍
    • 생성: create{Entity}
    • 조회: get{Entity}, get{Entities}
    • 업데이트: patch{Entity}, put{Entity}
    • 삭제: delete{Entity}
  • 서비스 메서드: Entity 명시
    • 생성: create{Entity}
    • 조회: find{Entities}, find{Entity}By{Criteria}
    • 복합 조회: read{Object}
    • 업데이트: update{Entity}
    • 삭제: delete{Entity}
  • 레포지토리 메서드: Entity 생략
    • 생성: save, create
    • 조회: findById, findAll, findBy{Criteria}
    • 업데이트: update
    • 삭제: delete

테스트 코드 네이밍 룰

jest 코드

describe('{layer}', () => {
  describe('{method}', async () => {
    it('should {result}{condition}', () => {});
  });
});

예시

AgreementsService
    createAgreement
      ✓ should return AgreementDto with valid input (6 ms)
    existCheck
      ✓ should throw exception when agreement does not exist (5 ms)
      ✓ should return AgreementDto when agreement exists (2 ms)

접두사 정리

엔티티 (Entity)

  • 접두사: ent_
  • 예시: ent_agreement

모듈 (Module)

  • 접두사: mod_
  • 예시: mod_

서비스 (Service)

  • 접두사: svc_
  • 예시: svc_agreements

레포지토리 (Repository)

  • 접두사: repo_
  • 예시: repo_agreements

컨트롤러 (Controller)

  • 접두사: ctrl_
  • 예시: ctrl_user

DTO (Data Transfer Object)

  • 접두사: dto_
  • 예시: dto_agreement

DB 관련 변수 (db connection pool 등)

  • 접두사: db_
  • 예시: db_redisQueue, db_dataSource

커밋 메세지과 머지 룰

커밋 컨벤션

커밋 메시지 양식

  • 커밋 메시지는 다음 형식을 따릅니다: 
    type(scope): subject
  • 예시: 
    refactor(user): change variables name

커밋 메시지 구성 요소

  • type: 커밋의 종류를 나타냅니다.
    • feat: 새로운 기능 추가
    • fix: 버그 수정
    • docs: 문서 변경
    • style: 코드 포맷팅, 세미콜론 누락 등 (비즈니스 로직에 변화가 없는 경우)
    • refactor: 코드 리팩토링 (기능 변화 없음)
    • perf: 성능 개선
    • test: 테스트 추가 또는 수정
    • chore: 빌드 과정 또는 보조 도구 수정 (라이브러리, 환경 설정 파일 등)
  • scope: 커밋 범위를 나타냅니다.
  • subject: 변경 사항에 대한 간결한 설명 (필수).

본문 내용 (선택 사항)

  • 필요한 경우, 본문에 추가 설명을 작성할 수 있습니다.
  • 왜 이 변경을 했는지, 무엇을 변경했는지에 대한 배경 정보를 포함할 수 있습니다.

머지 룰

브랜치 구조

  • develop: 개발 중인 브랜치
  • staging: 테스트 및 검증을 위한 브랜치
  • master: 프로덕션 배포를 위한 브랜치
  • {type}/{subject}: 세부 기능 개발을 위한 브랜치

머지 절차

  1. 개발 작업

    • 새로운 기능 또는 버그 수정은 개별 기능 브랜치에서 작업합니다.
    • 작업이 완료되면 develop 브랜치에 pr을 올립니다.

  2. 검토 및 테스트

    • 모든 변경 사항은 develop 브랜치에서 충분히 검토하고 테스트합니다.
    • 변경 사항이 검토되고 테스트가 완료되면 develop 브랜치를 staging 브랜치로 머지합니다.

  3. 스테이징 환경에서 검증

    • staging 브랜치에서 애플리케이션이 정상적으로 작동하는지 확인합니다.

    • 테스트가 완료되고 모든 기능이 정상 작동하면 staging 브랜치를 master 브랜치로 머지합니다.

      https://staging.api.blccu.com

  4. 프로덕션 배포

    • master 브랜치에 머지된 변경 사항은 프로덕션 환경에 배포됩니다.

      https://api.blccu.com