[내일배움캠프_사전캠프_8기]_Days_12 TIL_ 팀 프로젝트-Day4

TIL - 레이어드 아키텍처는 왜 사용할까?

오늘은 백엔드의 기본 구조인 레이어드(계층형) 아키텍처에 대해 배웠다.

단순히 Controller, Service, Repository를 나누는 것이 아니라 왜 이렇게 나누는지를 이해하는 것이 핵심이었다.

아키텍처란?

아키텍처는 코드가 어디에 위치하고, 어떻게 소통하며, 변경이 생겼을 때 영향이 어디까지 퍼지는지 설계하는 것이다.

레이어드 아키텍처는 시스템을 관심사별로 나눈 구조로, 가장 많이 사용되는 표준적인 방식이다.

Controller
    ↓
Service
    ↓
Repository
    ↓
Database

의존성은 위에서 아래로만 흐르며, 계층을 건너뛰거나 역방향으로 호출하면 안 된다.

계층을 나누는 이유

계층을 나누지 않으면 요청 처리, 비즈니스 로직, DB 접근을 하나의 클래스가 모두 담당하게 된다.

이런 클래스를 God Class라고 하며, 유지보수와 테스트가 매우 어려워진다.

그래서 Controller는 요청과 응답만, Service는 비즈니스 로직, Repository는 DB 접근만 담당하도록 역할을 분리한다.

DTO와 Entity의 역할

계층의 경계를 넘을 때는 Entity가 아니라 DTO를 사용한다.

• Request DTO → Entity → DB
• DB → Entity → Response DTO

Entity를 그대로 노출하면 DB 구조가 API에 그대로 드러나고, 민감한 정보가 노출될 위험도 있기 때문이다.

테스트가 쉬워지는 이유

계층이 분리되어 있으면 필요한 계층만 테스트할 수 있다.

예를 들어 Service를 테스트할 때는 Repository를 Mock으로 대체하면 되므로 DB 없이도 비즈니스 로직을 검증할 수 있다.

프로젝트 작업

오늘은 팀 프로젝트에서 User Entity와 LoginType, UserRoleEnum, UserStatus를 생성했다.

또한 Address 구조는 현재보다 확장성을 고려해 개선이 필요하다는 점도 확인했다.

팀에서는 시간 저장 방식을 UTC로 사용할지 논의했다. 찾아보니 UTC는 서버 위치와 관계없이 같은 기준 시간을 사용할 수 있어 확장성 측면에서 장점이 많다는 점을 알게 되었다.

오늘 배운 점

오늘 가장 크게 느낀 것은 계층은 나누기 위해 나누는 것이 아니라, God Class 같은 문제를 해결하기 위해 존재한다는 것이다.

앞으로도 "왜 이런 구조를 사용하는가?"를 먼저 생각하며 설계하는 습관을 가져야겠다.

 

---

내일 할 것

내일은 유저도메인 기능 구현 역할을 제대로 분배하고 난뒤에 유저도메인쪽을 빠르게 마무리해줘야 팀원들도 편하게 기능구현을 할수있을것같다. 최대 이틀안에 기능구현을 마칠예정이다.