🌒 Architecture Pattern

💫 아키텍처 패턴

---

• 서로 다른 시스템과 환경에서 시도되고 테스트된 우수한 사례를 정형화하고 추상화한 기술
• 이전 시스템에서 성공적이었던 시스템 구조 기술
• 해당 패턴을 언제 사용하기에 적절하고 적절하지 않은지에 대한 정보 포함
• 패턴의 강점과 약점에 대한 상세한 내용 포함
  

💫 MVC

---

Model, View, Controller의 약자
사용자 인터페이스로부터 비즈니스 로직을 세 가지 파트로 분리하여 서로 영향 없이 개발할 수 있는 설계가 가능

비즈니스 로직 : 사용자가 원하는 기능을 수행하기 위해 필요한 데이터를 처리하는 로직 (Input 받고, Process 하고, Output 내보내기)

• Model : DB와 연동하여 데이터를 처리하는 부분
• View : 사용자에게 보여지는 부분
  • 회원가입 버튼, 로그인 버튼
• Controller : 사용자의 입력을 받아 처리하는 부분
  • View에서 버튼을 누르면, Controller가 요청을 받아서 처리
    

🫧 Model

• 데이터를 처리하는 영역
• 데이터베이스와 연동을 위한 DAO(Data Access Object)와 데이터의 구조를 표현하는 DO (Data Object)로 구성됨

i.e. 검색을 위한 키워드가 넘어오면 DB에서 관련된 상품의 데이터를 받아 뷰에 전달

🫧 View

• 데이터를 보여주는 화면 자체의 영역을 뜻함
• 사용자 인터페이스(UI) 요소들이 여기에 포함되며, 데이터를 각 요소에 배치함
• 뷰에서는 별도의 데이터를 보관하지 않음

i.e.검색 결과를 보여주기 위해 모델에서 결과 상품 리스트 데이터를 받음

🫧 Controller

• 모델(Model)과 뷰(View) 사이에서 브릿지 역할을 수행
• 앱의 사용자로부터 입력에 대한 응답으로 모델 및 뷰를 업데이트하는 로직을 포함
• 사용자의 요청은 모두 Controller로 들어온다. (진행해야 한다.)
• 컨트롤러로 들어온 요청은 어떻게 처리할지 결정하여 모델로 요청을 전달함

i.e. 쇼핑몰에서 상품을 검색하면 그 키워드를 받아서 입력을 처리하여 모델과 뷰에 적절하게 전달

💫 Layered Architecture

---

MVC 패턴과 비슷한 이야기, 다만 레이어(계층) 기준으로 설명
유사 관심사를 레이어로 묶어 수평적으로 분리한 구조

일반적으로 3계층 또는 4계층으로 구성됨
프로젝트에 따라 커스터마이징해서 사용

🫧 Presentation

• 사용자 인터페이스를 제공하는 계층
• 사용자가 요청을 보냄
  

🫧 Business

• 비즈니스 로직을 처리하는 계층
• 사용자의 요청을 처리하고, 데이터를 처리하는 계층
  

🫧 Data (Access)

• 데이터베이스와 연동하는 계층
  

🫧 U_설명

• 서브 시스템의 인터페이스를 모델링하는데 이용
• 각 층이 서비스 집합을 제공하는 계층 집합(추상 머신)으로 시스템을 구성
• 상이한 계층에 있는 서브 시스템의 점증적 개발을 지원. 계층 인터페이스가 변경될 때, 인접 계층에만 영향을 줌.
  

🫧 U_장점

• 시스템의 점증적인 개발을 지원한다. 한 계층이 개발됨에 따라, 그 계층에 의해 제공되는 서비스들의 일부를 사용자가 이용할 수 있다.
• 변경 가능하며 이식 가능하다. 계층의 인터페이스가 변경되지 않는 한, 동등한 다른 계층에 의해 대체될 수 있다.
  

🫧 U_단점

• 시스템을 구조화하는 것이 어려울 수 있다. 최상위 수준의 사용자가 요구하는 서비스는 그 아래의 여러 계층이 제공하는 서비스에 접근하기 위해 인접 계층을 ‘뚫고 지나가야’ 할 수도 있다. 이런 방식은 시스템의 외부 계층이 바로 그 이전의 계층에 종속되지 않음에 따라 계층 모델을 망가뜨리게 된다.
• 여러 수준의 명령어 해석이 필요하기 때문에 성능이 문제가 될 수 있다. 최상위 계층으로부터의 서비스 요청은 처리되기 전에 상이한 계층에서 여러 번 해석되어야 한다.