[클린코드] 레이어드 아키텍처란 무엇이고, 왜 쓰는걸까?

클린코드, 어째서 중요할까? 

 

옛날에 매우 인기 있는 앱을 개발한 회사가 있었다. 

이 회사의 제품은 커다란 인기를 끌었고, 수많은 전문가들이 구매해 사용했다.

그런데 제품의 출시 주기가 점차 늘어지기 시작했다. 

이전 버전에 있었던 버그가 다음 버전에 그대로 남아 있고, 프로그램이 느려졌으며, 
동작하지 않는 일도 생기기 시작했다.

그렇게 점차 사용자들이 앱을 사용하지 않기 시작했고, 회사는 얼마 못가 망하게 되었다.


후일담으로 전해진 내부 사정은 이렇다.

다음 버전 출시가 바빠 코드를 마구 작성하였으며, 기능을 추가할수록 코드는 엉망이 되어갔고, 결국 감당이 불가한 수준에 이르렀다.

나쁜 코드 때문에 회사가 망한것이다..

로버트 마틴의 저서 <클린 코드>.

좋지 않은 코드들이 쌓이면 어떠한 일이 일어나는지 간단하지만 오싹한 사례가 나와있다.

 

 

 

안좋은 코드가 쌓이면, 시간이 지날 수록 생산성이 낮아진다.

 

생산성 대 시간

 

 

• 하나의 함수로 이루어진 3000줄의 코드를 상상해보자..

1. 그 함수를 동시에 여러명이 수정할 수 없다.
2. 그 함수를 읽고, 이해하는 것이 너무 어렵다.
3. 그 함수의 어느 부분을 수정하더라도 함수전체에 영향을 미칠 수 있기 때문에 함부로 
   건들수가 없다.
4. 너무 큰 기능이기 때문에 테스트도 힘들다.
5. 종합적으로 유지 보수성이 떨어진다.

 

@PutMapping("/user")
public void updateUser(@RequestBody UserUpdateRequest request) {
    String readSql = "SELECT * FROM user WHERE id=?";
    boolean isUserNotExist =  jdbcTemplate.query(readSql, (rs, rowNum) -> 0, request.getId()).isEmpty();
    if (isUserNotExist) {
        throw new IllegalArgumentException();
    }
    String updateSql = "UPDATE user SET name=? WHERE id=?";
    jdbcTemplate.update(updateSql, request.getName(), request.getId());
}

 

이해를 돕기 위한 간단한 예시.  
몇줄 되지도 않는 간단한 수정 API를 보더라도 
무려 3가지의 역할을 하고있다.

 

1. API의 진입 지점으로써 HTTP Body를 객체로 변환한다.

---

2. 현재 유저가 있는지 없는지 확인하고 예외처리를 한다.

---

3. SQL을 사용해 실제 DataBase와의 통신을 담당한다.

 

정리해보자면.....

1.  API의 진입 지점으로써 HTTP Body를 객체로 변환하고 있다.

2. 현재 유저가 있는지, 없는지 등을 확인하고 예외 처리를 해준다.

3. SQL을 사용해 실제 DB와의 통신을 담당한다.

updateUser() 함수를 역할별로 나눠봤더니 크게 3덩이로 나눌 수 있다는걸 알 수 있다.

---

레이어드 아키텍처의 구성

위 구성에 따라 레이어를 나눠보자.

 

1.&nbsp; API의 진입 지점으로써 HTTP Body를 객체로 변환하고 있다. //Presentation Layer (Controller)

---

2. 현재 유저가 있는지, 없는지 등을 확인하고 예외 처리를 해준다. //Business Layer(Service)

---

3. SQL을 사용해 실제 DB와의 통신을 담당한다. //Persistence Layer(Repository)

 

Presentation layer (Controller)
Presentation layer는 해당 시스템을 사용하는 사용자 혹은 클라이언트 시스템과 직접적으로 연결되는 부분이다.
백엔드 API에서는 엔드포인트들을 정의하고 전송된 HTTP요청(Request)를 읽어 들이는 로직을 구현한다.
그러나 그 이상의 역할은 담당하지 않고, 실제 시스템이 구현하는 비즈니스 로직은 다음 레이어로 넘긴다.

Business layer (Service)
Business layer는 이름 그대로 비즈니스 로직을 구현하는 부분이다. 
백엔드 API에서는 Presentation layer에서 전송된 요청을 읽고 요청에 맞게 동작하는 로직을 구현하면 된다.
예를 들어, 회원정보수정 요청시 필수적인 요소가 포함되어있지 않다면 거부하는등의 로직이 비즈니스 로직이다.

Persistense layer (Repository)
Persistense layer는 데이터 베이스와 관련된 로직을 구현하는 부분이다. 
Business layer에서 필요한 데이터를 생성,수정,읽기 등을 처리하며, 실제로 데이터베이스에서 데이터를 
저장,조회,수정,삭제 한다.

---

위와 같은 구조로 코드를 구현하면 각 레이어가 독립적이고 역할이 분명하므로 
코드의 구조를 파악하기 쉬울 뿐만 아니라 재사용 가능성도 높아진다.
또한, 테스트 코드의 작성 및 수행도 훨씬 수월해진다.

 

정리

각 계층 사이의 의존성을 줄여서 외부 변화로부터 비즈니스 로직의 변화를 막고, 애플리케이션의 유지보수와 확장성을 높이려는 목적으로 만들어진 설계의 한 방법

 

레이어드 아키텍처의 구성은 하나로 정해져 있지 않고,
애플리케이션의 크기, 복잡도, 요구사항 등에 따라 달라질수 있다.
계층의 명칭, 어떤 계층으로 나눴나 보단 레이어드 아키텍처를 사용하는 목적을 생각하며
코드를 만들수 있도록 하자..