아키텍처 패턴(Architecture Pattern)

아키텍처 패턴(Architecture Pattern)

아키텍처 패턴은 소프트웨어의 구조를 구성하기 위한 가장 기본적인 토대를 제시한다.

• 아키텍처 패턴은 각각의 시스템들과 그 역할이 정의되어 있고,
  여러 시스템 사이의 관계와 규칙 등이 포함되어 있다.
• 검증된 구조로 개발을 진행하기 때문에 안정적인 개발이 가능하다.
• 아키텍처 패턴을 도입할 경우 도메인이 복잡할수록 모델이나 코드를 더 쉽게 변경할 수 있다.

대표적인 아키텍처 패턴

• 저장소 패턴(Repository pattern)
  • 영속적인 저장소에 대한 추상화
• 서비스 계층 패턴(Service layer pattern)
  • 유스케이스(Usecase)의 시작과 끝을 명확하게 정의하기 위한 패턴
• 작업 단위 패턴(Unit of work pattern)
  • 원자적 연산을 제공한다.
• 애그리게이트 패턴(Aggregate pattern)
  • 데이터 정합성을 강화하기 위한 패턴

아키텍처 패턴을 도입하기 전에 고민해야 할 것

• 아키텍처 패턴이 주는 이익과 비용에 대해 확실한 이유가 있어야 한다.
• 해당하는 아키텍처 패턴을 채택했을 때 어떤 장단점이 존재하는지 명확하게 인지해야 한다.
• 여러 계층을 추가하기 위해 들이는 노력과 시간을 투자할만한 가치가 있을 정도로
  어플리케이션과 도메인이 복잡한 경우에만 아키텍처 패턴을 도입해야 한다.

 

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

계층형 아키텍처 패턴은 계층을 분리해서 관리하는 아키텍처 패턴이고,

현재 가장 흔하게 사용되고 있는 아키텍처 패턴 중 하나이다.

• 단순하고 대중적이면서 비용도 적게 들어 모든 어플리케이션의 사실상 표준 아키텍처이다.
• 어떤 아키텍처 패턴을 도입할지 확신이 없을 때에는 계층형 아키텍처 패턴은 좋은 선택지가 된다.
• 계층형 아키텍처 패턴은 어떤 경우든 계층을 분리해서 유지하고,
  각 계층이 자신의 바로 아래 계층에만 의존하게 만드는 것이 목표이다.

계층화의 핵심은 각 계층이 응집도(Cohesion)가 높으면서, 다른 계층과는 낮은 결합도(Coupling)를 가지고 있어야 한다.

상위 계층은 하위 계층을 사용할 수 있지만, 하위 계층은 자신의 상위 계층에 누가 있는지 알 수 없고, 

사용할 수 조차 없도록 구성해야 한다.

 

일반적으로 계층형 아키텍처 패턴의 경우 규모가 작은 어플리케이션의 경우 3개, 

크고 복잡한 경우 그 이상의 계층으로 구성된다.

 

3계층 아키텍처(3-Layered Architecture)

• 프레젠테이션 계층(Presentation Layer)
• 비즈니스 로직 계층(Business Logic Layer)
• 데이터 엑세스 계층(Data Access Layer)

계층형 아키텍처 패턴의 장점

• 관심사를 분리하여 현재 구현하려하는 코드를 명확하게 인지할 수 있다.
• 각 계층별로 의존성이 낮아 모듈을 교체하더라도 코드 수정이 용이하다.
• 각 계층별로 단위 테스트를 작성할 수 있어 테스트 코드를 조금 더 용이하게 구성할 수 있다.

3계층 아키텍처 처리과정

1. Controller: 어플리케이션의 가장 바깥 부분. 요청/응답을 처리한다.
   클라이언트의 요청을 처리한 후 서버에서 처리된 결과를 반환해주는 역할을 한다.
2. Service: 어플리케이션의 중간 부분, 실제 중요한 작동이 많이 일어나는 부분
   아키텍처의 가장 핵심적인 비즈니스 로직이 수행되는 부분이다.
3. Repository: 어플리케이션의 가장 안쪽 부분. DB와 맞닿아 있다.
   실제 데이터베이스의 데이터를 사용하는 계층이다.