Clean Architecture

1. 소프트웨어 아키텍처는 인적 자원을 최소화하고 생산성을 극대화하는 것

소프트웨어 아키텍처의 목표는 필요한 시스템을 구축하고 유지하는 데 필요한 인적 자원을 최소화하는 것이다.

아키텍처 결정은 중요하다. 좋은 아키텍처는 소프트웨어 시스템을 개발, 배포, 유지하는 데 필요한 노력을 줄여준다. 이는 팀이 독립적으로 작업할 수 있게 하고, 변경의 영향을 최소화하며, 시스템이 시간이 지남에 따라 진화할 수 있게 한다.

좋은 아키텍처의 주요 측면:

• 관심사의 분리
• 의존성 관리
• 구현 세부 사항의 추상화
• 미래 변경을 수용할 수 있는 유연성

이러한 측면에 집중함으로써, 아키텍트는 이해하기 쉽고 수정 및 확장이 용이한 시스템을 만들 수 있으며, 궁극적으로 시스템의 수명 동안 생산성을 높이고 비용을 줄일 수 있다.

2. 클린 아키텍처는 비즈니스 규칙을 외부 세부 사항과 분리한다

애플리케이션의 중심은 데이터베이스가 아니다. 또한 사용 중인 프레임워크도 아니다. 애플리케이션의 중심은 애플리케이션의 사용 사례이다.

비즈니스 규칙이 핵심이다. 클린 아키텍처는 코드를 동심원으로 조직하여 비즈니스 규칙을 중심에 두고 구현 세부 사항을 외부 레이어에 배치한다. 이러한 분리는 데이터베이스, 사용자 인터페이스 또는 프레임워크와 같은 외부 요인의 변경에도 핵심 비즈니스 로직이 영향을 받지 않도록 한다.

클린 아키텍처의 주요 레이어:

• 엔터티: 기업 전반의 비즈니스 규칙
• 사용 사례: 애플리케이션 특정 비즈니스 규칙
• 인터페이스 어댑터: 사용 사례와 외부 기관 간의 데이터 변환
• 프레임워크 및 드라이버: 외부 도구 및 기술

이 구조를 준수함으로써 개발자는 다음과 같은 시스템을 만들 수 있다:

• 변경에 더 유연하고 적응 가능
• 테스트 및 유지보수가 용이
• 특정 기술이나 프레임워크에 덜 의존

3. SOLID 원칙은 유연하고 유지보수 가능한 시스템을 만드는 데 도움을 준다

SOLID 원칙은 함수와 데이터 구조를 클래스에 배열하는 방법과 클래스 간의 상호 연결 방식을 알려준다.

SOLID는 모듈성을 향상시킨다. 이 다섯 가지 원칙은 이해하기 쉽고 유연하며 유지보수 가능한 소프트웨어 시스템을 만드는 지침을 제공한다. 이 원칙들은 변경에 강하고 확장하기 쉬운 코드를 설계하는 데 도움을 준다.

SOLID 원칙은 다음과 같다:

• 단일 책임 원칙: 클래스는 변경의 이유가 하나만 있어야 한다
• 개방-폐쇄 원칙: 소프트웨어 엔티티는 확장에는 열려 있어야 하지만 수정에는 닫혀 있어야 한다
• 리스코프 치환 원칙: 슈퍼클래스의 객체는 프로그램의 정확성에 영향을 주지 않고 서브클래스의 객체로 대체될 수 있어야 한다
• 인터페이스 분리 원칙: 많은 클라이언트 특정 인터페이스가 하나의 범용 인터페이스보다 낫다
• 의존성 역전 원칙: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다

이 원칙들을 적용함으로써 개발자는 변화하는 요구사항에 적응할 수 있는 더 견고하고 확장 가능한 소프트웨어 아키텍처를 만들 수 있다.

4. 컴포넌트는 클린 아키텍처의 구성 요소이다

컴포넌트는 배포 단위이다. 시스템의 일부로 배포될 수 있는 가장 작은 엔티티이다.

모듈식 설계는 유연성을 가능하게 한다. 클린 아키텍처의 컴포넌트는 독립적으로 배포 및 개발할 수 있는 시스템의 부분들이다. 이들은 관련 기능을 캡슐화하고 명확한 인터페이스를 가지며, 시스템의 유지보수 및 수정이 용이하게 한다.

잘 설계된 컴포넌트의 주요 특성:

• 높은 응집력: 관련 기능이 함께 그룹화됨
• 낮은 결합도: 컴포넌트 간의 최소한의 의존성
• 명확한 인터페이스: 명확하게 정의된 상호작용 방법
• 독립적 배포 가능성: 다른 부분에 영향을 주지 않고 업데이트 또는 교체 가능

시스템을 컴포넌트로 조직함으로써 아키텍트는:

• 다른 팀에 의한 병렬 개발을 촉진
• 더 쉬운 테스트 및 디버깅 가능
• 시스템의 점진적 업데이트 및 개선 가능
• 전체 시스템의 확장성 및 유지보수성 향상

5. 경계는 핵심 비즈니스 로직을 정의하고 보호한다

각 아키텍처 경계에서 우리는 겸손한 객체 패턴이 어딘가에 숨어 있는 것을 발견할 가능성이 높다.

경계는 핵심을 보호한다. 클린 아키텍처의 아키텍처 경계는 비즈니스 로직과 구현 세부 사항 간의 다른 관심사를 분리한다. 이러한 경계는 핵심 비즈니스 규칙이 외부 변경으로부터 독립성을 유지하도록 돕는다.

아키텍처 경계의 주요 측면:

• 레이어 간 상호작용을 정의하는 인터페이스 사용
• 의존성 역전을 통해 의존성이 내부로 향하게 함
• 경계를 넘어 정보를 전달하기 위한 데이터 전송 객체 사용
• 테스트 가능한 동작을 하드 테스트 컴포넌트로부터 분리하는 겸손한 객체 사용

명확한 경계를 설정함으로써 아키텍트는:

• 외부 시스템 또는 기술의 변경 영향 최소화
• 핵심 비즈니스 로직의 더 쉬운 테스트 가능
• 핵심 시스템에 영향을 주지 않고 구현 세부 사항 교체 가능
• 전체 시스템의 유연성 및 적응성 향상

6. 클린 아키텍처는 테스트 주도 개발과 독립적 배포를 촉진한다

좋은 아키텍처는 시스템이 변경되어야 하는 모든 방식으로 변경하기 쉽게 하며, 옵션을 열어둔다.

테스트 가능성과 유연성이 핵심이다. 클린 아키텍처는 시스템을 더 쉽게 테스트하고 독립적으로 배포할 수 있게 하는 관행을 촉진한다. 관심사를 분리하고 의존성을 관리함으로써 핵심 비즈니스 로직에 대한 단위 테스트를 작성하고 시스템의 다른 컴포넌트를 별도로 배포하는 것이 더 간단해진다.

클린 아키텍처의 테스트 및 배포에 대한 이점:

• UI, 데이터베이스 또는 외부 의존성 없이 핵심 비즈니스 규칙을 테스트 가능
• 다른 컴포넌트를 독립적으로 배포하여 더 쉬운 업데이트 가능
• 시스템의 한 영역에서의 변경이 다른 영역에 미치는 영향 최소화
• 기존 기능을 손상시키지 않고 새로운 기능 추가 가능

이러한 특성은 다음을 초래한다:

• 더 빠른 개발 주기
• 배포 시 위험 감소
• 시스템 신뢰성 향상
• 새로운 기술을 채택하거나 기존 기술을 변경하는 데 더 큰 유연성

7. 프레임워크와 데이터베이스는 아키텍처 요소가 아닌 구현 세부 사항이다

프레임워크는 사용해야 할 도구이지, 준수해야 할 아키텍처가 아니다.

핵심 로직은 프레임워크에 구애받지 않아야 한다. 클린 아키텍처는 프레임워크와 데이터베이스를 핵심 비즈니스 로직에 영향을 미치지 않는 외부 세부 사항으로 취급한다. 이러한 접근 방식은 이러한 외부 요소를 변경하거나 업데이트하더라도 시스템의 핵심 기능에 영향을 미치지 않도록 한다.

프레임워크와 데이터베이스를 처리하는 주요 원칙:

• 핵심 비즈니스 로직에 플러그인으로 취급
• 의존성 역전을 사용하여 핵심 로직을 독립적으로 유지
• 데이터베이스 작업에 대한 추상화 생성
• 프레임워크 및 데이터베이스 결정을 가능한 한 늦게 지연

이 접근 방식의 이점:

• 프레임워크와 데이터베이스를 더 쉽게 변경하거나 업그레이드 가능
• 외부 변경에도 핵심 비즈니스 로직이 안정적으로 유지
• 벤더 종속성 감소
• 핵심 시스템 컴포넌트의 테스트 가능성 향상

8. 웹은 클린 아키텍처에서 또 다른 전달 메커니즘일 뿐이다

웹은 전달 메커니즘이며, 애플리케이션 아키텍처는 이를 그렇게 취급해야 한다.

비즈니스 로직은 전달 메커니즘에 구애받지 않는다. 클린 아키텍처에서 웹은 데이터베이스나 프레임워크와 마찬가지로 외부 세부 사항으로 취급된다. 이러한 관점은 웹 애플리케이션, 데스크탑 앱 또는 API와 같은 특정 전달 메커니즘에 구애받지 않고 핵심 비즈니스 로직을 독립적으로 유지할 수 있게 한다.

클린 아키텍처에서 웹 애플리케이션에 대한 주요 고려 사항:

• 웹 특정 코드를 핵심 비즈니스 로직과 분리
• 웹 형식과 내부 데이터 구조 간 변환을 위한 인터페이스 어댑터 사용
• 웹 프레임워크를 핵심 시스템의 플러그인으로 취급
• 웹 특정 문제와 독립적인 사용 사례 설계

이 접근 방식의 이점:

• 다른 전달 메커니즘에 시스템을 더 쉽게 적응 가능
• 여러 플랫폼에서 핵심 비즈니스 로직 재사용 가능
• 웹 의존성 없이 비즈니스 규칙 테스트 간소화
• 웹 기술을 변경하거나 업데이트하는 데 더 큰 유연성

9. 클린 임베디드 아키텍처는 하드웨어 문제를 비즈니스 로직과 분리한다

소프트웨어는 마모되지 않지만, 하드웨어에 대한 관리되지 않은 의존성으로 인해 내부에서 파괴될 수 있다.

하드웨어 독립성은 중요하다. 클린 임베디드 아키텍처는 임베디드 시스템에 클린 아키텍처 원칙을 적용하여 하드웨어 특정 문제를 핵심 비즈니스 로직과 분리한다. 이러한 분리는 하드웨어 구성 요소의 업데이트를 더 쉽게 하고 소프트웨어의 이식성을 향상시킨다.

클린 임베디드 아키텍처의 주요 요소:

• 하드웨어 추상화 레이어(HAL)로 하드웨어 특정 코드를 격리
• 장치 독립적인 비즈니스 로직
• 하드웨어와 소프트웨어 컴포넌트 간의 명확한 인터페이스
• 하드웨어 의존성을 관리하기 위한 의존성 역전 사용

임베디드 시스템에서 이 접근 방식의 이점:

• 새로운 하드웨어 플랫폼으로 소프트웨어를 더 쉽게 포팅 가능
• 하드웨어 의존성 없이 핵심 로직 테스트 간소화
• 하드웨어 변경이 전체 시스템에 미치는 영향 감소
• 임베디드 소프트웨어의 유지보수성 및 수명 향상

10. 마이크로서비스와 서비스 지향 아키텍처는 클린 아키텍처 원칙의 혜택을 받을 수 있다

시스템의 아키텍처는 소프트웨어 요소를 서로 분리하고, 한쪽의 요소가 다른 쪽을 알지 못하도록 제한하는 경계에 의해 정의된다.

클린 원칙은 모든 규모에 적용된다. 클린 아키텍처는 종종 모놀리식 애플리케이션의 맥락에서 논의되지만, 그 원칙은 마이크로서비스 및 서비스 지향 아키텍처에도 효과적으로 적용될 수 있다. 이러한 원칙은 개별 서비스의 독립성과 테스트 가능성을 유지하면서 분산 시스템의 복잡성을 관리하는 데 도움을 준다.

마이크로서비스에 클린 아키텍처 적용:

• 각 마이크로서비스를 자체 클린 아키텍처를 가진 경계된 컨텍스트로 취급
• 서비스 간 통신을 위한 명확한 인터페이스 사용
• 서비스 간 의존성 역전 적용
• 서비스의 독립적 배포 가능성 유지

마이크로서비스에서 클린 아키텍처의 이점:

• 전체 시스템의 모듈성 및 확장성 향상
• 개별 서비스를 더 쉽게 이해하고 유지보수 가능
• 서비스 진화 및 교체에 더 큰 유연성
• 서비스 간 결합도 감소로 더 견고한 시스템 구축

Last updated: July 26, 2024