Jaekyeong1 / Bullet-Box

🌀 불렛박스 Backend

📦 Bullet Box(불렛 박스)

내가 직접 의미를 부여하는 나만의 투두 리스트

📦 Bullet Box 둘러보기

목차

1. 프로젝트 소개
2. 프로젝트 아키텍처
   2-1. 서비스 아키텍처
   2-2. 패키지 구조
   
3. 코드 컨벤션
4. ERD
5. API 명세
6. 기술적 의사결정
   6-1. builder의 private화/정적 팩토리 메소드 활용
   6-2. FACADE 패턴
   6-3. 계층 별 DTO 분리
   

1.프로젝트 소개

항해 10기 A반 1조 [Bullet Box]

• 불렛저널을 통한 스케줄러 + 다이어리 서비스
• 단순히 할 일, 완료만 있는 TODOLIST가 아닌 다양한 속성을 가진 TODOLIST
• 서비스 환경: 웹/모바일 모두 가능합니다
  

2.프로젝트 아키텍처

🛠기술 스택

2-1.서비스 아키텍처

2-2.패키지 구조

패키지 구조

3.코드 컨벤션

🔍 NOTION 문서

4.ERD

5.API 명세

API 명세서

📜 API 명세

6.기술적 의사결정

6-1

builder의 private화/정적 팩토리 메소드 활용

본 프로젝트에선 객체 외부에서 객체를 생성할 때 생성자 대신 static 메소드를 사용합니다.
static 메소드에선 Builder를 사용하여 객체를 생성합니다.

이때 Builder는 Lombok의 @Builder 어노테이션을 통해 구현하며, 생성자와 Builder는 모두 private으로 사용합니다.
그렇기에 객체 외부에선 해당 객체의 생성자와 Builder를 모두 사용할 수 없고,
오로지 static 메소드를 통해서만 해당 객체를 생성할 수 있습니다.

Builder와 생성자의 private화


static 메소드에서의 Builder 사용


외부에서 static 메소드를 통해 객체를 생성하는 모습

Builder는 매개 변수가 많아질 때 가독성이 높고, 작성하기가 쉽다는 장점이 있습니다.
하지만 생성자와 static 메소드처럼 객체의 형태를 강제할 수 없기에 다양한 형태의 객체가 생성될 수 있다는 단점이 있습니다.

특히 Builder는 보통 public으로 만들어지기에 외부에서 이상한 형태의 객체가 무분별하게 생성될 수 있습니다.
그럴 경우 Builder가 어디서 어떻게 사용되고 있는지 모르기에 디버깅하기가 더욱 어려워집니다.

하지만 Builder를 private으로 한다면 Builder의 장점은 살리면서도 단점은 최소화할 수 있습니다.
혹여나 Builder로 인한 문제가 생기더라도 해당 객체만 디버깅하면 되기에 유지/보수가 쉬워집니다.

static 메소드를 함께 사용하는 이유는 캡슐화 때문입니다.
static 메소드와 Builder를 함께 사용하면 내부 구현에 변화가 생겼을 때 그 파급 효과를 최소화 할 수 있습니다.

6-2

FACADE 패턴

본 프로젝트에선 다음 그림과 같이 기존 Spring 웹 계층에서 Facade 계층을 추가하여 사용합니다.

기존에는 Service 계층에서 비즈니스 로직과 데이터 접근이라는 두 가지 일을 한꺼번에 처리하였는데,
Facade 계층을 도입하여 두 업무를 분리하였습니다.

Facade 계층에서는 비즈니스 로직을 처리하고, 새로운 Service 계층에서는 데이터 접근과 관련된 업무만 진행합니다.

새로운 Service 계층만 Repository에 의존하며 Controller와 Facade 계층에서는 Repository에 의존하지 않고,
Entity도 사용하지 않습니다. 두 계층에서는 오로지 DTO 만 사용합니다.

바뀐 Service 계층에는 각 Entity와 Repository를 사용하기 위한 Service 클래스들이 존재합니다.
해당 클래스들의 이름은 해당 Entity 이름 + Service로 구성되어 있습니다.

Diary Entity를 사용하기 위한 DiaryService

Facade 계층을 추가함으로써 얻은 이점은 다음과 같습니다.

1. Entity 노출을 최소화하여 Entity 사용으로 인해 발생할 수 있는 문제를 해결 및 예방합니다.
   
2. 여러 비즈니스 로직에서 공통적으로 사용하는 메소드들을 새로운 Service 계층에서 관리할 수 있습니다.
   
3. 역할이 세분화되어 코드의 재사용성이 높고, 기존보다 유지/보수가 수월해집니다.
   

6-3

계층 별 DTO 분리

6-2에서 확인할 수 있듯이 저희의 웹 계층은 다음과 같이 이루어져 있습니다.

본 프로젝트에선 Presentation Layer, Business Layer 에서 사용하는 DTO들을 크게 3종류로 분리하여 사용합니다.

Controller에서 외부 요청을 받기 위한 RequestDto, 외부에 응답을 보내기 위한 ResponseDto,
Business Layer에서 사용하기 위한 EntityDto 이렇게 3 종류로 사용합니다.

EntityDto는 특정 Entity를 대체하는 DTO이며, Facade 계층에서 요청을 받거나 보낼 때는 주로 EntityDto를 사용합니다.

DTO를 분리해서 사용하여 얻는 이점은 다음과 같습니다.

1. Facade 계층에 있는 메소드들이 보편적인 DTO (EntityDto)를 매개변수로 받아 사용하므로 메소드의 재사용성이 높아집니다.
   또한 보편적인 DTO를 사용하기 때문에 다른 팀원이 작성한 코드의 흐름을 이해하기가 쉬워져 협업 능률이 올라갑니다.
   
2. DTO가 세분화되어 있기에 유지/보수가 수월해집니다.
   예를 들어 Request 값이 변경되었을 때 해당 변경으로 인한 파급 효과는 보통 Controller 계층에만 미치게 됩니다.

👥팀원소개

BackEnd

김민호
한교진
전재경