3.4 애플리케이션 아키텍처 선정

[jongfeel]

3.4 애플리케이션 아키텍처 선정

3.4.1 애플리케이션 아키텍처 검토

애플리케이션은 모듈과 컴포넌트로 구성됩니다.
이를 검토할 때 중요한 기준은 애플리케이션의 설계 원칙으로 선정한 아키텍처 스타일입니다.

3.4.2 레이어드 아키텍처

레이어드 아키텍처layered achitecture는 애플리케이션을 여러 개의 레이어(층)로 나누고, 각 계층의 역할을 명확히 구분하여 해당 역할에 맞는 컴포넌트를 배치하는 아키텍처입니다.
3계층 아키텍처가 일반적이지만, 레이어의 개수는 설계에 따라 달라질 수 있습니다.

계층별 책임이 명확히 구분되므로, 레이어드 아키텍처는 단일 책임 원칙 (SRP)을 애플리케이션 아키텍처 수준에서 적용한 구조라고 할 수 있습니다.

레이어드 아키텍처의 단점 중 하나는 상위 계층인 도메인 계층이 하위 계층인 데이터 액세스 계층에 의존하게 된다는 점입니다.
도메인 계층은 더 추상적이고 안정적인 구조인 반면, 데이터 액세스 계층은 구현에 가까워 더 자주 바뀔 수 있기 때문입니다.

이 문제점을 해결하기 위해 의존성 역전 원칙(DIP)을 적용한 변형된 레이어드 아키텍처가 고안되었습니다.
어떤 아키텍처를 설계하든 애플리케이션에서 가장 중요한 도메인 계층을 중심으로 설계됩니다.

클린 아키텍처

클린 아키텍처는 로버트 C. 마틴이 제창한 설계 구조입니다.

클린 아키텍처에서는 외부 계층에서 내부 계층으로 향하는 의존성만 허용됩니다. 즉 내부에서 외부로의 의존이 일어나는 일은 절대 없어야 합니다.

클린 아키텍처에서는 도메인 계층을 가장 중요한 계층으로 설계하며, 이를 실현 하기 위해 의존성 역전 원칙을 적용한 추상화 작업이 핵심 요소가 됩니다.
하지만 이를 구현하려면 높은 수준의 설계가 필요하고 인터페이스와 컴포넌트의 수가 증가하여 복잡성이 커질 수 있다는 점에 유의해야 합니다.

도메인 계층에서 복잡한 비즈니스 규칙을 구현하면 코드의 가독성과 유지보수성이 향상되지만, 그만큼 복잡성도 증가하는 트레이드오프가 발생합니다.

3.4.3 파이프라인 아키텍처

파이프라인 아키텍처pipeline architecture는 파이프와 필터 pipes and filters라고도 부릅니다.

파이프라인 아키텍처의 대표적인 예로 유닉스 셸unix shell을 들 수 있습니다.

3.4.4 마이크로커널 아키텍처

마이크로커널 아키텍처microkernel architecture는 애플리케이션의 확장성을 높이기 위한 아키텍처로, 플러그인 아키텍처 plug-in architecture라고도 불립니다.

이 아키텍처의 주된 목적은 고객 맞춤형 기능이 추가될 때도 코어 시스템이 직접적인 영향을 받지 않도록 하는 것입니다.
이를 위해 SOLID 원칙의 개방-폐쇄 원칙(OCP)을 적용하여 확장성을 보장합니다.
구체적으로는 미리 확장 가능한 지점을 정의하고, 해당 지점에 삽입할 수 있는 컴포넌트의 인터페이스를 정의하는 방식입니다.

실제로는 패키지형 소프트웨어에서 코어 시스템 자체가 거대한 모놀리스로 존재하는 경우도 많습니다.
이런 점을 고려하면 플러그인 아키텍처라는 명칭이 더 쉽게 와닿을 수도 있습니다.

주의해야 할 점은 필요한 확장 포인트를 도출하고 인터페이스를 정의하는 작업이 결코 쉽지 않다는 것입니다.
애플리케이션 사용 경험이 쌓일수록 새로운 확장점extension point이 필요해지거나 기존 인터페이스를 수정해야 하는 상황이 잦아질 수 있습니다.

3.4.5 애플리케이션 아키텍처의 사례 연구

표 3.9 서비스별 애플리케이션 아키텍처 예시

서비스 분류	채택한 아키텍처 스타일
경비 정산 서비스	클린 아키텍처, 마이크로커널 아키텍처
워크플로 서비스	클린 아키텍처
증빙 관리 서비스	레이어드 아키텍처
자동 분개 서비스	파이프라인 아키텍처
부정 탐지 서비스	파이프라인 아키텍처