23/12/03 TIL __ 3계층 아키텍쳐

 

 

🐣 상황

3계층 아키텍쳐.. 말만 들어왔는데,

드디어 이부분에 대해 알게되어 정리한다. 

 

 

---

 

🤍  3계층 아키텍쳐

 

          1. mvc 패턴

          2. 클린 아키텍쳐 패턴

          3. 마이크로 서비스 아키텍쳐 패턴

          4. 계층형 아키텍쳐 패턴

 

 

일단 이정도로 간략히 살펴보고, 그중에서 계층형 아키텍쳐 패턴에 대해 자세히 알아보자. 

 

 

 

 

🚍   MVC 패턴

• 소프트웨어 디자인 패턴 중 하나
• 모델: 데이터베이스와 비지니스 로직
• 뷰 : 사용자 인터페이스 UI 담당
• 컨트롤러 : 클라이언트의 요청을 모델과 뷰로 전달해 주는 역할.

 

• 컨트롤러는 사용자의 요청을 해석하고 그에 따른 행동을 결정하는 역할을 수행
• 컨트롤러는 모델과 뷰 사이 중간 매개체 역할
• 예전에 프론트와 백이 하나의 파일에서 관리되던 때 나옴.
• 백엔드 아키택쳐 이긴 하지만 백만 있는거 아님.

 

 

📷   클린 아키텍쳐 패턴( the clean Architecture)

• 의존성이 외부에서 내부로 흘러간다.
• 최종 핵심
• 로직은 제일 안쪽임.
• 클라이언트의 요청 처리, 데이터베이스 조작, 외부 시스템과의 통신은 외부 계층에서 처리
• 소프트웨어의 유지보수성과 확장성을 향상시키는 것이 주요 목표
• 계층형 아키텍쳐 사용하면서 만난 문제들을 클린 아키텍쳐 패턴으로 좋아질 수 있다고 한다. 

클린 아키텍쳐 패턴과, 계층형 아키텍쳐 패턴의 차이점.

클린 아키텍쳐 패턴
    > 고수준 모듈이 저수준 모듈에 의존하지 않고, 둘다 추상화에 의존하도록 장려
    > 외부로부터 내부로의 의존성 최소화. 외부 요소에 독립적 내부 구조를 만드는데 초점.
    > 내부요소와 외부요소 사이의 경계를 관리. 인터페이스를 통해 분리.
    > 즉 외부 요소의 변화에 덜 민감한 내부구조 만든다.
    > 경계를 명확히. 
    > 외부변화가 내부구조에 미치는 영향을 최소화.
    

계층형 아키텍쳐 패턴
    > 모듈화 되고, 분리된 시스템을 만드는데 중점.
    > 그러나 고수준 모듈이 저수준 모듈에 의존하지 않고, 둘다 추상화에 의존하도록 장려 하진 않음.
    > 순차적 의존관계. 위계층이 바로 아래 계층에 의존. 그러나 위로는 의존하지 않도록. 
    > 각 계층이 특정한 역할과 책임을 가짐.
    > 계층간의 상호 의존성을 명확하게 설정하는데 초점을 맞춤.
    > 외부 변화시 내부에 변화가 전파되는 경향 있음.

 

 

 

🐣   마이크로 서비스 아키텍쳐 패턴 (Microservices Architecture Pattern)

• MSA 라고도 불림.
• 작고 독립적인 서비스로 분활. 각 서비스는 특정 비지니스 기능 담당, 독립적 배포 확장 관리..
• 시스템을 작고, 독립적으로 배포 가능한 서비스로 분할하는 패턴
• 상호 의존성 최소화.
• 각 서비스들이 다른 언어를 사용해도 상관 없음.
• 각 서비스가 서로 다른 데이터베이스를 선택해도 상관 없음.
• 서비스가 독립적으로 선택한 최적의 기술을 사용할 수 있도록 한다.
• 하나의 시스템에서 다양한 언어와 프레임워크를 도입할 수 있는 패턴
• 비대한 서비스를 작게 작게 유지하기에 아주 좋은 패턴임.
• 서비스 간의 통신은 API 또는 이벤트 기반 아키텍처(EDA, Event Driven Architecture)를 통해 통신.
• 어떤 언어를 사용하던 각각 서비스 마다 작게 작게 구현되는 장점이 있음.

 

 

---

 

 

 

🚗   계층형 아키텍처 패턴(Layered Architectur Pattern)

 

• 현재 가장 널리 채택되고 있는 아키텍처 패턴.
• 단순하면서 대중적, 비용도 적게 들어서  표준 아키텍쳐 라고 할 수 있음.
• 어떤 언어를 쓰던, 어떤 프레임 워크를 사용하던 이 패턴을 사용하면, 해당 코드가 대략적으로 어떤 역할을 하는지 인지할 수 있게 됨.
• 계층화의 핵심 __ 각 계층이 높은 응집도를 가지면서, 다른 계층과는 결합도를 최소화 하는 것.
• 각 계층을 명확하게 분리해 유지함.
• 각 계층이 자신의 바로 아래 계층에만 의존하게 만드는게 목표임.
• 각 계층은 바로 아래 계층과만 상호작용 하며, 위 계층에만 서비스 제공.
• 상위계층은 하위계층 사용 가능
• 하위계층은 자신이 어떤 상위 계층에 속하는지 알 필요 없이 독립접으로 동작할 수 있어야 한다. 
• 이런 분리 구조는 시스템을 더 모듈화 하고,
• 변경사항 발생시, 영향을 최소화 해 유지보수와 확장성을 높인다.
• 아래 계층에는 의존하며, 위로는 의존 하지 않는다. 즉 순차적 의존성 관계.
• 각 계층이 특정한 역할과 책임을 가지도록 함.
• 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 좀더 용이하게 구성 가능.

 

 

 

1. 표현계층 Presentation Layer  __ 컨트롤러

• 사용자 인터페이스 UI를 처리.
• 사용자와 시스템간 상호작용 담당.
• 웹 브라우저나 앱의 UI 부분이 여기에 해당
• 입력을 받아들이고, 정보를 표시하는 역할.
• 요청 수신후 결과 반환하는 역할임.
• 클라이언트와 서버가 가장 처음 만나게 되는 부분
• 라우터도 여기에 해당한다 볼 수 있다.
  • 라우터는 주로 표현 계층(Presentation Layer)에 속하며, 클라이언트의 요청을 받아들이고 요청된 URL 및 HTTP 메소드에 따라 적절한 컨트롤러로 라우팅하는 역할을 수행합니다. 라우터는 요청을 받아들여 이를 해당하는 컨트롤러로 전달하여 비즈니스 로직이 실행되도록 하며, 그 결과를 클라이언트에게 반환합니다.
• 하위 계층의 내부구조에 대해 신경쓰지 않는다.
• 외부에 공개된 메서드를 호출하기만 하면 됨.
• 이게 가능한 이유는 추상화의 특성 덕분.
• 서비스 계층으로 전달만 하면 됨.
• 서비스 계층이 어떤 내부구조로 비지니스 로직을 수행하는지는 컨트롤러 계층에게 중요하지 않음
• 하위계층인 서비스 계층, 저장소 계층에서 발생하는 예외를 처리.
• 클라이언트가 전달한 데이터에 대한 유효성 검증 기능 수행.
• 요청 처리후 서버에서 처리된 결과를 반환함.

 

 

2.  서비스 계층 Business Layer __ 서비스

• Application Layer(응용계층) 과 , Domain Layer(도메인 계층)을 포괄하거나 단일화 하는 용어로 Business Layer가 사용
• 핵심 로직이 작성되는 부분
• 회원가입 및 로그인을 예로 들자면 사용자 인증등
• 서비스 계층 핵심 비지니스로직, 정렬, 받은 데이터 가공해서 중요한 정보노출 안되도록 하는것도 비지니스 로직 중 하나.
• 비지니스 영역과 관련된 모든 로직과 프로세스를 담당한다.
• 프레젠테이션 계층과 데이터 엑세스 계층 사이에 중간다리 역할이며, 서로 다른 두 계층이 직접 통신하지 않도록 만들어 준다.
• 근데 어플리케이션의 규모가 커질수록 서비스 계층의 역할과 코드의 복잡성도 점점 더 커지게 된다. 서비스 계층이 점점 비대해 질 수 있음.!

 

• 서비스 계층의 장점
  • 사용자 유즈케이스와 워크플로우를 명확히 이해하고, 이해할 수 있도록 도와줌.
  • 즉 게시글 작성부분의 코드를 보려면 클래스만 보면 됨.
  • 또한 비지니스 로직이 api 뒤에 숨겨져 있음으로 서비스 계층의 코드 자유롭게 수정하거나 리펙터링 가능.__ 비지니스 로직 찾기 쉽고, 수정도 간편하다는 말임.
  • 하위계층에 저장소패턴 (Repository Pattern)및 가짜 저장소(Fake Repository)와 조합하면, 높은 수준의 테스트를 작성할 수 있다.

 

 

• 서비스 계층의 단점.
  • 서비스 계층 또한 다른 추상화 계층임으로 잘못 사용하면 코드의 복잡성을 증가시킬 수 있다
  • 메소드명 명확하게 작성해야함.
  •  
  • 한 서비스 계층이 다른 서비스 계층에 의존하는 경우 의존성 관리가 복잡해 진다.
  • 의존성 관리에 대한 부분 고민
  •  
  • 한 서비스 계층에 너무 많은 기능을 넣으면, 빈약한 도메인 모댈과 같은 안티 패턴이 생길 수 있다.
  • 과하지 않고 적지 않게 코드 구현하기

 

 

 

 좀더 딥하게 들어가 보자.

응용계층 과 , 도메인 계층에 대해 살펴보자. 

 

 

 

• 응용계층 (Application Layer) _ ui와 도메인계층 사이의 매개체 _
  • 사용자 인터페이스 UI와 도메인 계층 사이의 매개체 역할을 한다.
  • 즉 사용자 인터페이스 UI와 데이터베이스 또는 외부 시스템 사이에 중간계층으로 동작.
  • 사용자 요청 받아들이고, 해당 요청을 처리하기 위한 도메인 객체나 서비스 호출하는 역할.
  • 그리고 그 결과를 사용자에게 표시하는 역할을 한다.
  • 비지니스 규칙과 관련된 기능들을 제공하며, 사용자 입력에 따라 적적한 도메인 로직을 호출하거나 제어.

 

• 도메인 계층 ( Domain Layer)
  • 비지니스의 핵심 개념이 정의된다.
  • 비지니스 로직 실행, 상태유지, 비지니스 요구사항 충족을 위한 로직 구현.
  • 주문, 고객, 제품 같은 핵심 도메인 객체를 다루며, 상호작용 정의.
  • 데이터 엑세스 계층(Persistence Layer) 를 통해 데이터베이스에 접근하기 때문에 직접적으로 데이터베이스에 의존하지 않는다.
  • 또한 도메인 계층 테스트 시에, 데이터베이스에 직접 의존하지 않고, 가짜 데이터나 목업 데이터를 사용해 테스트 하기 쉬워진다. 

 

 

 

 

비지니스 로직이란

• 소프트웨어가 비지니스 요구사항을 충족하기 위해 수행하는 계산, 규칙, 프로세스등 추상적 부분 의미
  
  
  • 1. 규칙 및 조건. : 특정 조거에 따라 시스템 어떻게 동작할지 에 대한 규칙. 
    > 예를들면, 구매 주문이 특정 가격 이상이면, 할인을 적용하는 규칙 등이 있겠다.
    
    
  •  2. 연산 및 계산. : 데이터나 입력에 기초해 값을 계산하거나 처리하는 로직 정의.
    > 예를들어 쇼핑카트에서 총 주문가격을 계산하는 것이 여기에 해당
    
    
  • 3. 예외 처리. : 예상하지 못한 상황에 대비해서 예외를 처리하는 규칙 정의한다. 
    >  주문 처리중 재고부족이나 결제오류 같은 상황을 다루는 로직이 이에 해당.소프트웨어가 비지니스 요구사항을 충족하기 위해 수행하는 계산, 규칙, 프로세스등 추상적 부분 의미

 

 

3.  저장소 계층 Persistence Layer (데이터 엑세스 계층)

• 영속성 계층, 저장소 계층
• 데이터베이스나 외부 시스템과의 상호작용 담당.
• 데이터 영구 저장 및 검색 처리
• 데이터 베이스에 있는 내용에 접근하기 위해 db 메소드를 사용하는 부분.
• 저장소 계층 : 데이터 접근과 관련된 세부사항을 숨기는 동시에, 메모리 상에 데이터가 존재하는 것처럼 가정하여 코드를 구현한다.
• 저장소 계층을 도입하면, 데이터 저장 방법을 더욱 쉽게 변경 가능하며, 테스트 코드 작성시 가짜 저장소(Mock Repository) 를 제공하기 더 쉬워진다. 얘만 갈아끼우면 되니깐.
• 어플리케이션의 다른 계층은 저장소의 세부 구현방식에 대해 알지 못하더라도 해당 기능을 사용 할 수 있다. 즉 저장소 계층의 변경 사항이 다른 계층에 영향을 주지 않는다.
• 이건 객체지향의 개념중 추상화와 관련이 있다.
• 또한 저장소 계층은 데이터 저장소를 간단히 추상화 한것. 이 계층을 통해 모델 계층과 데이터 계층을 명확히 분리할 수 있다.

 

    - 저장소 계층의 장점
        - 데이터 모델과 데이터 처리 인프라에 대한 사항을 분리.
        - 따라서 단위 테스를 위한 가짜 저장소(Mock Repository)를 쉽게 만들기 가능
        - 도메인 모델 미리 작성, 처리해야 할 비지니스 문제에 더 잘 집중할 수 있음.
        - 겍체를 테이블에 매핑하는 과정을 원하는대로 제어할 수 있어서 db 스키마를 단순화 할 수 있다.
        - 저장소 계층에  ORM을 사용하면 어떤걸 사용하던 다른 데이터 베이스로 쉽게 전환 가능하다. 

    - 저장소 계층의 단점.
        - 저장소 계층이 없더라도 ORM 은 모델과 저장소의 결합도를 충분히 완화 시키기 가능.
        - orm이 없던 때에는 대부분 코드가 raw query로 작성되었기 때문.
        - orm 매핑을 수동으로 하려면 개발 코스트 더 소모됨.

 

 

 

---

스파르타 측에서 제공한 강의자료에 이런 글이 있었는데, 정리가 잘 되어 가져왔다. 

이해하기 좀더 쉬웠다. 

 

 

계층화의 핵심은 각 계층이 높은 응집도(Cohesion)를 가지면서, 다른 계층과는 결합도(Coupling)를 최소화 하는 것입니다. 여기서 상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 자신이 어떤 상위 계층에 속하는지 알 필요없이, 독립적으로 동작할 수 있어야합니다.

예를 들어, 데이터 엑세스 계층 (Data Access Layer)은 비즈니스 로직 계층 (Business Logic Layer)에 어떤 코드들이 있는지 알 수 조차 없고, 사용하면 안된다는 거겠죠?

일반적으로 계층형 아키텍처 패턴의 경우 규모가 작은 어플리케이션의 경우 3개의 계층, 크고 복잡한 경우는 그 이상의 계층으로 구성됩니다.

 

3-Layered Architecture에서는 아래의 플로우.

1️⃣ 클라이언트(Client) 어플리케이션에 요청(Request)을 보냅니다.
2️⃣ 요청(Request)을 URL에 알맞은 컨트롤러(Controller)가 수신 받습니다.
3️⃣ 컨트롤러(Controller)요청을 처리하기 위해 서비스(Service) 호출합니다.
4️⃣ 서비스(Service)는 필요한 데이터를 가져오기 위해 저장소(Repository)에게 데이터를 요청합니다
5️⃣ 서비스(Service)는 저장소(Repository)에서 가져온 데이터를 가공하여 컨트롤러(Controller)에게 데이터를 전달합니다.
6️⃣ 컨트롤러(Controller)는 서비스(Service)의 결과물(Response)을 클라이언트(Client)에게 전달해줍니다.

 

 

 

 

---