클린 아키텍처

아키텍처란?

아키텍처가 무엇인지에 대한 감이 꽤나 오랜 기간 잡히지 않았다. 누군가가 디렉토리 구조를 아키텍처라고 칭하는 것을 보기도 했고, 또 어디서는 설계 원칙이라고 하는 것을 보기도 했다.

정의는 아래와 같다고 한다.

the fundametal organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.

시스템의 근본적인 구조, 이를 구성하는 컴포턴트, 컴포넌트들 간의 상호 관계 및 환경과의 관계, 그리고 시스템의 설계와 발전을 지배하는 원칙 이락고 한다.

이게 도대체 무슨 말인가…? 검색을 거듭한 결과 다음의 결론을 내렸다:

---

아키텍처의 구성 요소

• 모듈: 시스템의 특정 기능을 수행하는 코드의 집합. 모듈들 간의 결합도를 최소화하여 독립적으로 개발 및 테스트가 가능하도록 설계.
• 컴포넌트: 시스템 내에서 재사용 가능한 코드의 단위. 특정 인터페이스를 구현하고, 다른 컴포넌트와 상호작용함.
• 계층: 시스템을 논리적으로 분리한 구조. 각 계측은 특정 역할을 담당하며, 상위 계층은 하위 계층에 의존하지만 그 반대는 성립하지 않음.
• 인터페이스: 모듈이나 컴포넌트 간의 상호작용을 정의하는 계약. 특정 기능을 외부에 노출하며 이를 통해 결합도를 낮추고 유연성을 높임.

아키텍처의 주요 역할

• 구조 설계: 시스템을 모듈, 컴포넌트, 계층 등으로 나누어 각각의 역할 및 관계 정의.
• 비기능적 요구사항 충족: 성능, 확장성, 보안, 유지보수성, 신뢰성 등의 비기능적 요구사항을 충족.
• 의사결정 지원: 개발 초기 단계에서 중요한 기술적 결정을 내리는 데 필요한 지침 제공.

---

이를 종합해 보면, ‘조직과 서비스의 이익을 위하여 적용하는 설계 도면’ 정도로 한줄 요약할 수 있을 것 같다.

클린 아키텍처

클린 아키텍처는 계층 구조로 구성되며, 4개의 계층을 포함한다.

1. 엔터티 (Entity)
   • 비즈니스 규칙을 포함한, 핵심 객체들을 정의하는 계층
   • 해당 계층의 코드는 다른 외부 요인들에 영향을 받지 않아야 함

비즈니스 규칙 (Business Rule)

컴퓨터 프로그램에서 데이터를 생성/표시/저장/변경하는 부분

1. 유스케이스 (Use Cases)
   • 서비스의 특정 기능을 정의하고 수행하는 계층
   • 엔터티와 상호작용하며, 서비스가 수행해야 하는 작업들 정의
   • 시스템의 동작을 나타내며, 비즈니스 규칙을 이용하여 특정 시나리오를 처리
2. 인터페이스 어댑터 (Interface Adapters)
   • 유스케이스와 외부 세계(DB, Web, API, UI, etc) 간의 상호작용을 관리하는 계층
   • 데이터 변환, 인터페이스 구현 등을 통해 외부 시스템과 유스케이스 계층을 연결
3. 프레임워크 및 드라이버 (Frameworks & Drivers)
   • 외부 기술적 세부사항을 포함하는 계층
   • DB, Web Framework, UI, 외부 라이브러리 등
   • 다른 계층에 영향을 주지 않음

출처: The Clean Coder Blog

의존성 규칙

클린 아키텍처의 가장 중요한 규칙 중 하나로, 소스 코드의 의존성은 항상 안쪽 계층을 향해야 한다. 즉, 안쪽 계층은 바깥쪽 계층에 대한 어떤 것도 참조하지 않아야 한다.

장점

1. 유지보수 용이성
   • 의존성 규칙을 적용하여 비즈니스 로직과 외부 요소들을 분리한다. 이를 통해, 코드 변경이 특정 계층에 국한되며, 다른 계층에 미치는 영향이 최소화된다.
2. 테스트 용이성
   • 비즈니스 로직이 독립적으로 유지되기 때문에 단위 테스트가 매우 용이하다. DB나 API등의 외부 의존성을 모의 객체로 대체하기 쉽기 떄문에 테스트 환경을 구성하기 수월하다.
3. 유연성 및 확장성
   • 시스템의 특정 부분(DB, UI 등)을 쉽게 교체할 수 있다.
4. 재사용성
   • 비즈니스 로직이 다른 서비스에 재사용될 수 있다.

단점

1. 초기 설계 복잡성
   • 초기 설계 단계에 많은 시간이 소요될 수 있다. 작은 프로젝트에서는 과도한 설계가 될 수도 있어 적절하게 적용해야 한다.
2. 과도한 추상화
   • 무리한 적용은 코드에 과도한 추상화를 초래하며, 코드의 이해도와 디버깅에 대해 어려움을 불러올 수 있다.
3. 성능 저하 가능성
   • 계층을 통한 추상화가 과도할 경우 성능에 영향을 미칠 수 있다.