백엔드 Layered Architecture 구조와 모델 설정시 유의할 점[20221108-TIL]

레이어드 아키텍쳐를 구성할 때 유의할 점

사실 제목이 적절한지나 모르겠다. 아직 아키텍쳐의 이해도 많이 부족한데 그래도 잠시나마 오늘 코딩의 신 아샬님 특강을 보고 느낀점이 있어 적어보려고 적절한 제목을 정하다보니 저렇게 되었다.

 

설계시 고민 점

일단 백엔드를 구성하면 크게 

1. Controller

2. Service

3. Repository 

+ Model

라는 구조를 두었다.

 

컨트롤러는 인터페이스 측면에서 최소한의 코드만 가지고 프론트에서 들어오는 쿼리나 파람을 처리해주는 최소의 로직과 DTO 변환하는 코드정도만 있으려고 했다.

 

첫번째 문제. 컨트롤러가 지저분해짐

그러나 이는 컨트롤러에서 처리해야할 서비스가 매우 간략하고 복잡도가 적을 때 가능한 것이었고 모델과 엔터티가 많아지고 서비스가 서로 교류하는게 많아지면서 지저분해지는 것을 막을 수 가 없었다.

 

1. 추상화(메소드화)

일단 추상화는 보는 사람의 인지부하를 줄이려고 한다고 한다. 우리가 걷는 사람을 볼 때 저 사람은 앞 발을 내밀고 반대 손을 뒤로 저은 후 다시 왼발이 따라오는 구나라고 인지하지 않는다. 우리가 그렇게 인지할때는 육상선수의 뜀박질을 분석할 때 뿐일 것이다. 따라서 코드가 지저분해지거나 가독성이 떨어지면 어떻게 추상화시켜 가독성을 높일까를 고민한다.

 

2. 로직은 뒤에서

논리를 처리해주는 로직은 서비스에서 이루어진다. 사실 서비스에서 이루어진다고 해도될지 모르겠다. 서비스는 로직들이 구성되고 그러한 개별적 로직들은 각각의 모델이나 값객체들이 지니고 있고 서비스는 그것이 이루어지는 장소? 라고 나는 오늘 생각하기로했다.(나중에 틀리다면 수정하거나 보완 글을 올리겠다.)

 

두번째 문제. 간단한 어플리케이션을 구성하는데에도 모델이 가진 속성값이 너무 많음.

 

이것의 문제는 일단 테스트 코드를 짤 때에도 이런 모델을 선언하고 생성함에 따라 지저분한 코드가 많아지고 식별하기 어렵다는 것이다.

 

1. fake의 모델을 생성하여 인지부하를 낮춘다.

말 그대로 모델을 생성할때에도 너무 정보가 많으면 가독성이 떨어진다. fake model을 만들어서 가독성을 높여주자.

2. 어떠한 설계를 할지 고민하며 값 객체를 만든다.

엔터티의 속성이 너무 비대하다면 속성을 값 객체로 만들어준다.

사실 왜 이것들 값객체로 빼주나 라는 고민이 많았는데 이는 내가 만드는 어플리케이션의 목적성에 따라 다르다고 한다.

값 객체의 속성들의 연결성이 커지면 엔터티에서 논리들을 전부 처리해야하는데

 

예) 제품이라는 엔터티에서 가격이라는 값객체는 Long price 라고 해주면 간단하지만 차후에 할인 이벤트를 진행한다던지 기간에 따라 가격이 변동하는 시즌 성 제품이라면 값 객체로 빼두어 논리를 처리하는게 편하다.

 

즉 위와 같이 나의 어플리케이션의 확장성 활용성등을 생각하며 코드를 짜는 것이 좋다고 한다.

물론 설계를 가장 베스트로 하는 것이 좋겠지만 초보자인 내가 그러기는 어렵고 실제로 복잡도가 높은 서비스의 경우 숙련된 개발자가 와도 단번에 완전한 설계로 구성해서 척척 코드를 짜기는 어려울 것 이다.

 

즉 나는 확장성이나 로직이 명백한 것들을 제외하곤 처음에는 String 과 Long 으로 속성을 준 후 작업을 하면서 고쳐나가기로 했다. (물론 일의 양은 더 많다.)

 

위의 두 가지만 지켜도 일단 내 코드가 깔끔해질 것 같으니 저렇게 해보고 다시 피드백 받고 돌아오겠다!

 

 

https://wikibook.co.kr/article/layered-architecture/

LAYERED ARCHITECTURE(계층형 아키텍처) | 위키북스