아키텍처 패턴 (Architecture Pattern)
아키텍처 패턴은 소프트웨어의 구조를 구성하기위한 가장 기본적인 토대를 제시한다.
예를 들면, 아키텍처 패턴은 각각의 시스템들과 그 역할이 정의되어 있고, 여러 시스템 사이의 관계와 규칙 등이 포함되어 있고, 검증된 구조로 개발을 진행하기 때문에 안정적인 개발이 가능하다. 또한 복잡한 도메인 문제를 해결할 때, 아키텍처 패턴을 사용하면 모델이나 코드를 더 쉽게 변경할 수 있다는 측면에서 큰 이익을 얻을 수 있다.
대표적인 아키텍처 패턴
MVC 패턴(Model View Controller Pattern)
- 사용자 인터페이스(UI)가 필요한 어플리케이션에서 많이 사용되는 패턴
- 모델(Model): 데이터와 비즈니스 로직을 담당
- 뷰(View): 사용자 인터페이스(UI)를 담당
- 컨트롤러(Controller): 클라이언트의 요청을 모델과 뷰로 전달해주는 역할을 담당
계층형 아키텍처 패턴(Layered Architecture Pattern)
- 시스템의 서로 다른 기능을 여러 계층(Layer)으로 분할하는 패턴
- 일반적으로 컨트롤러(Controller), 서비스(Service), 저장소(Repository) 계층으로 분리됨
클린 아키텍처 패턴(Clean Architecture)
- 소프트웨어를 내부 도메인으로 향하는 의존성을 가지는 여러 계층으로 분리하는 패턴
- 클라이언트의 요청 처리, 데이터베이스 조작, 외부 시스템과의 통신은 외부 계층에서 처리
- 소프트웨어의 유지보수성과 확장성을 향상시키는 것이 주요 목표
마이크로 서비스 아키텍처 패턴(Microservices Architecture Pattern)
- 시스템을 작고, 독립적으로 배포 가능한 서비스로 분할하는 패턴
- 하나의 시스템에서 다양한 언어와 프레임워크를 도입할 수 있는 패턴
- 서비스 간의 통신은 API 또는 이벤트 기반 아키텍처(EDA, Event Driven Architecture)를 통해 통신한다.
아키텍처 패턴을 도입하기 전에 고민해야 할 것
- 아키텍처 패턴이 주는 이점과 비용에 대한 확실한 이유가 있어야한다.
- 해당하는 아키텍처 패턴을 채택했을 때 어떤 장단점이 존재하는지 명확하게 인지해야 한다.
- 여러 계층을 추가하기 위해 들이는 노력과 시간을 투자할 만한 가치가 있을 정도로 어플리케이션과 도메인이 복잡한 경우에만 아키텍처 패턴을 도입해야 한다.
- 만약 가벼운 어플리케이션에 복잡한 아키텍처 패턴을 도입하는건 의미 없는 코스트가 소모될 수 있음.
계층형 아키텍처 패턴 (Layered Architecture Pattern)
계층형 아키텍처 패턴(Layered Architecture Pattern)은 시스템을 여러 계층으로 분리하여 관리하는 아키텍처 패턴으로 현재 가장 널리 채택되고 있는 아키텍처 패턴 중 하나이다.
단순하고 대중적이면서 비용도 적게 들어 사실상 모든 어플리케이션의 표준 아키텍처로, 어떤 아키텍처 패턴을 도입할지 확신이 없을 때에는 계층형 아키텍처 패턴은 좋은 선택지가 될 수 있다.
계층형 아키텍처 패턴은 각 계층을 명확하게 분리해서 유지하고, 각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것이 목표이다.
-
계층화의 핵심은 각 계층이 높은 응집도(Cohesion)를 가지면서, 다른 계층과는 결합도(Coupling)를 최소화 하는 것이다. 여기서 상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 자신이 어떤 상위 계층에 속하는지 알 필요없이, 독립적으로 동작할 수 있어야한다.
-
일반적으로 계층형 아키텍처 패턴의 경우 규모가 작은 어플리케이션의 경우 3개의 계층, 크고 복잡한 경우는 그 이상의 계층으로 구성된다.
3계층 아키텍처(3-Layered Architecture)
3계층 아키텍처에서 구성되는 각각의 계층(Layer)는 아래와 같다.
- 프레젠테이션 계층 (Presentation Layer)
- 비즈니스 로직 계층 (Business Logic Layer)
- 데이터 엑세스 계층 (Data Access Layer) | 영속 계층(Persistence Layer)
계층형 아키텍처 패턴의 장점
계층형 아키텍처 패턴은 시스템을 계층별로 아키텍처를 분리했을때 아래의 장점을 얻을 수 있다.
- 관심사를 분리하여 현재 구현하려하는 코드를 명확하게 인지할 수 있으며,
- 각 계층은 서로 독립적이며, 의존성이 낮아 모듈을 교체하더라도 코드 수정이 용이하다.
- 또한 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 조금 더 용이하게 구성할 수 있다.
3계층 아키텍처 구성
3계층 아키텍처의 구성으로는 아래 3가지 계층으로 구성된다.
- 컨트롤러(Controller) : 어플리케이션의 가장 바깥 부분, 요청/응답을 처리한다.
- 클라이언트의 요청(Request)을 수신 한 후 서버에서 처리된 결과를 반환(Response)해주는 역할을 담당한다.
- 서비스(Service) : 어플리케이션의 중간 부분, API의 핵심적인 동작이 많이 일어나는 부분
- 아키텍처의 가장 핵심적인 비즈니스 로직이 수행되는 부분이다.
- 저장소(Repository) : 어플리케이션의 가장 안쪽 부분으로, 데이터베이스와 맞닿아 있다.
- 실제 데이터베이스와 통신하는 계층이다.
- 또한 3-Layered Architecture에서는 아래의 플로우를 기반으로 로직이 수행된다.
- 클라이언트(Client)가 어플리케이션에 요청(Request)을 보냅니다.
2. 요청(Request)을 URL에 알맞은 컨트롤러(Controller)가 수신 받습니다.
3. 컨트롤러(Controller)는 요청을 처리하기 위해 서비스(Service)를 호출합니다.
4. 서비스(Service)는 필요한 데이터를 가져오기 위해 저장소(Repository)에게 데이터를 요청합니다.
5. 서비스(Service)는 저장소(Repository)에서 가져온 데이터를 가공하여 컨트롤러(Controller)에게 데이터를 전달합니다.
6. 컨트롤러(Controller)는 서비스(Service)의 결과물(Response)을 클라이언트(Client)에게 전달해줍니다.
- 클라이언트(Client)가 어플리케이션에 요청(Request)을 보냅니다.
