아키텍처 패턴

소프트웨어를 구성하기 위한 기본적인 토대를 제시한다
-> 시스템과 역할이 정의되어 있고 관계와 규칙이 포함되어있다

협업하거나 수정할 일이 잦을 때에 효율적이다

아키텍처 패턴

• 저장소 (repository pattern)**(많이 쓴다)

• 서비스 계층 (service layer pattern)**(많이 쓴다)

• 작업 단위 패턴 ( unit of work pattern )

• 애그리게이트 패턴 (aggregate pattern )

@고려해야할 것

1. 적용에 있어 이익과 비용에 대해 확실한 이유가 있어야 한다
2. 장단점에 대해 명확하게 인지해야한다
3. 복잡한 경우일수록 유리하다

layerd architecture pattern

계층을 분리해서 관리하는 패턴, 가장 흔하게 사용한다

-> 계층을 분리해서 유지하고, 각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것을 목표로 한다

계층화

• 각 계층은 응집도가 높다, 다른 계층과는 결합도가 낮다
• 상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 상위 계층에 누가 있는지 알 수 없다

3 layer architecture pattern

1. 프레젠테이션 계층 (presentation layer)
2. 비즈니스 로직 계층 (business logic layer)
3. 데이터 엑세스 계층 (data access layer)

아래에서 위로 작동한다

• 계층별로 관심사를 분리해 코드를 명확하게 인지한다
• 계층별로 읜존성이 낮아 모듈을 교체할 때 수정이 용이하다
• 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 용이하게 구성할 수 있다

구성

1. controller => 가장 바깥 부분, 요청& 응답을 처리한다
   -요청을 처리한 후 서버에서 처리된 결과를 반환해준다

2. service => 중간 부분, 가장 중요한 작동이 많이 일어난다
   -비즈니스 로직이 수행되는 부분

3. repository => 가장 안쪽 부분, DB와 맡닿아 있다

수행 과정

1. client 가 요청을 보낸다 (req)
2. 요청을 controller 가 수신받는다
3. controller 가 요청을 처리하기 위해 service 를 호출한다
4. service 가 필요한 데이터를 가져오기 위해 repository 에 데이터를 요청한다
5. repository 에서 가져온 데이터를 가공해서 controller 에게 전달한다
6. controller 는 service 의 결과물을 client 에게 전달한다 ( res)