[클린 아키텍처] 클린 아키텍처 5-2 부, Architecture

클린 아키텍처의 관점 의존성 규칙: 안으로 갈수록 높은 수준의 정책이다. 입력과 출력에서 멀어질수록 높은 수준의 정책이다. UI, 웹은 입력과 출력에 해당하므로 클린 아키텍처에서 가장 낮은 수준의 정책이며 엔티티의 경우 원 안쪽에 존재하기 때문에 가장 높은 수준의 엔티티이다. 높은 수준의 모듈은 낮은 수준에 의존해서는 안 된다. 그 결과 엔티티는 다른 어떤 것에도 의존해서는 안 된다. 엔티티: 앱의 핵심 업무에 필요한 데이터 또는 함수 집합 유스 케이스: 엔티티를 활용하여 서비스에 필요한 코어 로직을 생성하고, 사용 사례는 엔티티에 변화를 주어서는 안 되며 외부의 다른 데이터에 의해 영향을 받아서는 안 된다. 유스케이스가 변화하는 유일한 이유는 앱의 비즈니스 로직이 변경된 상황이다.ex) 은행이 복리로 부여한 금리를 단리로 변경한 경우 인터페이스 어댑터: 엔티티와 유스 케이스에서 사용되는 데이터 형식을 출력이나 입력 장치로 변화시킬 수 있도록 지원한다. 우리는 인터페이스를 사용하기 때문에 세부 사항에서 자유로워질 수 있다. 어댑터만 재정의하면 쉽게 바꿀 수 있기 때문이다. 프레임워크, 드라이버: 모든 세부사항이 존재하는 장소, 웹의 경우 react를 사용할지 vue.js를 사용할지 mysql을 사용할지 msql을 사용할지와 같은 비즈니스 방향에 따라 결정하면 된다. 23장 프레젠터와 험블 오브젝트 험블 오브젝트는 하나의 디자인 패턴이다. 테스트하기 쉬운 객체와 테스트하기 어려운 객체를 나누어 작성하는 기법을 말한다. 이와 같이 분리함으로써 로직과 View의 테스트 책임을 분리시켜 테스트를 보다 간단하게 할 수 있는 방법이다. 험블 오브젝트 패턴은 mysql의 데이터와 usecase의 데이터를 연결하는 데 사용되는 gateway와 역할이 동일하지만 gateway 인터페이스를 구현된 mock 오브젝트를 생성하여 테스트를 쉽게 분리할 수 있다. 제24장 부분적 경계 아키텍처의 경계를 나누는 것은 수고스러운 일이다. 특히 앱이 개발되는 단계에서는 계속 바뀌기도 한다. 그렇기 때문에 처음부터 아키텍처를 모두 나누어 만드는 것은 비효율적이라고 느낀다. 이런 것들을 조금이라도 줄이기 위해 부분적 경계라는 개념을 소개한다. 컴포넌트를 분리하는 경계를 긋기 위한 작업을 수행하는 대신 하나의 컴포넌트에서 인터페이스와 폴더 패키지의 정도를 분리하는 간단한 경계만 작성해도 시스템 초기 단계에서는 충분히 효율적으로 사용할 수 있다. ex)1차원 경계, 파사드 패턴 등이 활용되는 27장 크고 작은 모든 서비스가 최근 MSA가 화두로 떠오르면서 각 서비스를 분리하는 것이 마치 아키텍처를 나누는 방식처럼 취급되고 있지만 엄밀히 말하면 아키텍처를 분리하는 것과 단순히 서비스를 나누는 것은 별개다. 오히려 개발 배포를 하기 위해 디팝스라는 추가적인 업무만 늘어날 수 있다. 단일 서비스로 구성돼 있더라도 의존관계가 있다면 오히려 수정의 유지보수가 어렵다는 사실을 고양이 택시의 예를 통해 보여준다. MSA에서 서비스를 구성하더라도 앞서 언급한 아키텍처 규칙을 지켜 앱을 개발해야 한다. 29장 클린 임베디드 아키텍처 지금까지 설명한 아키텍처를 임베디드 관점에서 살펴본다. 해당 장은 간단하게 진행하겠습니다. 결론부터 말하면 앞서 언급한 경계를 잘 지키자. 임베디드의 경우 하드웨어와 직접적으로 통신하기 위해 해당 메이커로부터 펌웨어를 제공한다. 임베디드 서비스가 해당 펌웨어에 의존할 경우 펌웨어 변경에 따라 코드를 유지보수해야 하는 경우가 많아진다. 전술한 높은 수준의 유스 케이스가 낮은 수준의 펌웨어를 참조하는 상황 이외에도 다양한 임베디드 시스템의 osal, hal 등의 상황에서도 인터페이스를 분리하여 독립적으로 사용할 필요성에 대해 언급하고 있다.지금까지 해왔던 것과 마찬가지로 자체적인 인터페이스를 활용해 의존성을 분리할 필요가 있다.데이터 클래스 DeopositEntity(밸브 밸런스: 수치, 레이트: 번호, 유효기간: Number)funcalDepositUseCase(보증금 엔티티: 입금 엔티티): float {return deposit.balance.toInt() * (1 + rate.toFloat().pow(duration.toInt())}유스 케이스는 순수한 해당 언어로만 구성되어 있다. 그 결과 예금 복리를 계산하는 입력이 휴대전화에 들어왔는지, 은행 창구 컴퓨터에서 들어왔는지 알 필요가 없다. 즉 입출력 장치, 데이터 소스로부터 독립적으로 구성되어야 한다. 21장 외치는 아키텍처의 잘 구성된 아키텍처는 아키텍처만으로 어떤 서비스를 하고자 하는지 알아야 한다. 테스트를 쉽게 할 수 있어야 해. 아키텍처는 프레임워크가 아니다. 전술한 바와 같이 순수한 언어로만 작성되기 때문에 프레임워크로부터 독립적이다. 22장 클린 아키텍처 클린 아키텍처는 다음과 같이 구성되어 있다.클린 아키텍처의 시각 의존성 규칙:안으로 갈수록 높은 수준의 정책이다. 입력과 출력에서 멀어질수록 높은 수준의 정책이다. UI, Web은 입력과 출력에 해당하기 때문에 클린 아키텍처에서 가장 저 수준의 정책이며, 주체의 경우는 엔화의 안쪽에 존재하므로 가장 높은 수준의 주체이다. 고 수준의 모듈은 저 수준에 의존해서는 안 된다. 그 결과 주체는 다른어떤 것에도 의존해서는 안 된다. 주체:앱의 핵심 업무에 필요한 데이터 또는 함수의 집합 유스 케이스:주체를 활용하고 서비스에 필요한 코어 논리를 생성하고, 활용 사례는 주체에 변화를 주어서는 안 되고 외부의 다른 데이터에 의해서 영향을 받아서는 안 된다. 유스 케이스가 변화하는 유일한 이유는 앱의 비즈니스 로직이 변경된 상황이다.ex)은행이 복리로 준 금리를 단리로 변경할 경우 인터페이스 어댑터:로 활용 사례에서 사용되는 데이터 형식을 출력이나 입력 장치에 변화할 수 있도록 지원한다. 우리는 인터페이스를 사용하므로 상세로 자유롭게 된다. 어댑터만 재정의하면 쉽게 바꾸기 때문이다. 체제 드라이버:모든 세부 사항이 존재하는 장소, 웹의 경우 react를 사용하거나 vue.js를 사용하거나 mysql을 사용할지 msql을 사용하는 듯한 비즈니스의 방향으로 결정하면 된다. 제23장 프레젠터와 험블 객체 험블 객체는 하나의 디자인 패턴이다. 테스트하기 쉬운 오브젝트와 테스트하기 어려운 객체를 나눠서 작성하는 기법을 말한다. 이렇게 분리하면 논리와 view의 시험 책임을 분리시키고 시험을 보다 쉽게 할 수 있는 방법이다. 험블 객체 유형은 mysql의 데이터와 usecase의 데이터를 연결하는 데 사용되는 gateway와 역할이 같지만, gateway의 인터페이스를 구현된 mock객체를 생성하고 테스트를 쉽게 분리할 수 있다. 제24장 부분적 경계 아키텍처의 경계를 나누는 것은 수고가 드는 것이다. 특히 앱이 개발되는 단계에서는 자주 바뀌는 것도 있다. 그래서 처음부터 아키텍처를 모두 나누고 만드는 것은 비효율적이라고 느낀다. 이런 일을 조금이라도 줄이기 위해서 부분적 경계라는 개념을 소개한다. 컴포넌트를 분리하는 경계를 긋기 위한 작업을 하는 대신 1개의 컴포넌트에서 인터페이스와 폴더 패키지의 정도를 분리하는 간단한 경계만 작성해도 시스템의 초기 단계에서는 충분히 효율적으로 사용할 수 있다. ex)한차원 경계, 파사드 패턴 등이 활용되는 27장 대소 모든 서비스가 최근 MSA가 화두로 부상하고 각 서비스를 분리하는 것이 마치 아키텍처를 가리는 방식처럼 취급 받고 있지만, 엄격히 말하면 아키텍처를 분리하는 것과 단순 서비스를 나누는 것은 별개다. 오히려 개발 배포를 하느라 devops라는 추가적인 업무만 늘어날 가능성이 있다. 단일 서비스로 구성되어 있어도 의존 관계가 있으면 오히려 수정의 유지가 어렵다는 사실을 고양이 택시의 예를 통해서 나타내고 있다. MSA에서 서비스를 구성하더라도, 전술한 아키텍처의 룰을 지키고 앱을 개발해야 한다. 29장 청정 임베디드 아키텍처 지금까지 설명한 아키텍처를 임베디드인 관점에서 본다. 해당장은 쉽게 진행합니다. 결론부터 말하면 전술한 경계를 잘 지키다. 임베디드인 경우 하드웨어와 직접적으로 통신하기 위해서 해당 제조 업체에서 펌웨어를 제공한다. 임베디드 서비스가 해당 펌웨어에 의존할 경우 펌웨어의 변경에 응하고 코드를 관리해야 하는 경우가 많아진다. 전술한 고 수준의 활용 사례를 저 수준의 펌웨어를 참조하는 상황 이외에도 다양한 임베디드 시스템의 osal, hal등의 상황에서도 인터페이스를 분리하고 독립하고 사용할 필요성을 언급하고 있다.지금까지 해왔던 것과 마찬가지로 자주적인 인터페이스를 활용하고 의존성을 분리할 필요가 있다.