본문 바로가기
[책 정리] 33. 사례 연구 : 비디오 판매 - Clean Architecture 제품 유스케이스 분석 - 단일 책임 원칙에 따르면 이들 엑터가 시스템이 변경되어야 할 네 가지 주요 근원이 된다. 신규 기능을 추가하거나 기존 기능을 변경해야 한다면, 그 이유는 반드시 이들 액터 중 하나에게 해당 기능을 제공하기 위해서다. 따라서 우리는 시스템을 분할하여, 특정 엑터를 위한 변경이 나머지 액터에게는 영향을 미치지 않게 만들어야 한다. - 점선으로 둘러싸인 유스케이스는 추상 유스케이스이다. 이들은 범용적인 정책을 담고 있으며, 다른 유스케이스에서 이를 더 구체화한다. (추상 유스케이스가 꼭 필요하지는 않다.) 컴포넌트 아키텍처 - View, Presenter, Interator, Controller 로 분리된 전형적인 분할 방법을 사용할 수 있다. 이중 선은 아키텍처 경계를 나타낸다. 뷰.. 2022. 11. 14.
[책 정리] 32. 프레임워크는 세부사항이다. - Clean Architecture - 유용한 프레임워크가 많다. 하지만 프레임워크는 아키텍처가 될 수 없다. 프레임워크 제작자 - 프레임워크가 풀려는 문제와 당신의 문제는 꽤 많이 겹칠 것이다. 겹치는 영역이 크면 클수록 프레임워크는 실제로 더 유용해진다. 혼인 관계의 비대칭성 - 당신과 프레임워크 제작자 사이의 관계는 놀라울 정도로 비대칭적이다. 당신은 프레임워크를 위해 대단히 큰 헌신을 해야 하지만, 프레임워크 제작자는 당신을 위해 아무런 헌신도 하지 않는다. - 대게의 경우 프레임워크 제작자는 프레임워크를 어떻게 통합할 수 있을지 조언한다. 이들은 프레임워크를 중심에 두고 우리의 아키텍처는 그 바깥을 감싸야 한다고 말한다. 또한 이들은 프레임워크의 기반 클래스에서 직접 파생하거나, 프레임워크의 기능들을 업무 객체에 바로 임포트(im.. 2022. 11. 13.
[책 정리] 31. 웹은 세부사항이다. - Clean Architecture 끝없이 반복하는 추 - 앞으로도 우리는 연산 능력을 어디에 둘지 알 수 없을 것이다. 연산 능력을 중앙에 집중하는 방식과 분산하는 방식 사이에서 우리는 끊임없이 움직인다. 이러한 진동은 한동안 계속될 것이다. - 업무 규칙을 UI 로부터 분리해야 한다. 요약 - GUI 는 세부사항이다. 웹은 GUI 다. 따라서 웹은 세부사항이다. 그리고 아키텍트라면 이러한 세부사항을 핵심 업무 로직에서 분리된 경계 바깥에 두어야 한다. 결론 - 추상화는 만들기 쉽지 않고, 제대로 만들려면 수차례의 반복 과정을 거쳐야 할 것이다. 하지만 가능하다. 그리고 세상은 마케팅 귀재로 가득하기 때문에 이러한 추상화가 꼭 필요할 때가 많다고 주장하기는 어렵지 않다. 끝 2022. 11. 12.
[책 정리] 30. 데이터베이스는 세부사항이다. - Clean Architecture - 아키텍처 관점에서 볼 때 데이터베이스는 엔티티가 아니다. 즉 데이터베이스는 세부사항이라 아키텍처의 구성요소 수준으로 끌어올릴 수 없다. 데이터베이스는 데이터 모델이 아니다. 데이터베이스는 일개 소프트웨어일 뿐이고, 데이터에 접근할 방법을 제공하는 유틸리티다. 이러한 유틸리티는 저수준의 세부사항(메커니즘)일 뿐이라서 아키텍처와는 관련이 없다. 관계형 데이터베이스 - 앱의 유스케이스는 데이터를 행 단위로 배치한다는 방식을 알아서는 안 되며 관여해서도 안 된다. 데이터가 테이블 구조를 가진다는 사실은 오직 아키텍처의 외부 원에 위치한 최하위 수준의 유틸 함수만 알아야 한다. 많은 데이터 접근 프레임워크가 테이블과 행이 객체 형태로 시스템 여기 저기에서 돌아다니게 허용하는데, 아키텍처적으로 잘못된 설계다. .. 2022. 11. 11.
[책 정리] 29. 클린 임베디드 아키텍처 - Clean Architecture - 소프트웨어는 닳지 않지만, 펌웨어와 하드웨어에 대한 의존성을 관리하지 않으면 안으로부터 파괴될 수 있다. - ROM 에 상주하는 코드만이 펌웨어는 아니다. 저장되는 위치가 펌웨어를 정의하지는 않는다. 이보다는 무엇에 의존하는지, 그리고 하드웨어 발전에 맞춰 수정하기가 얼마나 어려운지에 따라 정의된다. 하드웨어는 발전할 수밖에 없고, 그러한 현실을 염두에 두고 임베디드 코드를 구조화할 수 있어야 한다. - 펌웨어는 더 적게 만들고, 소프트웨어는 더 많이 만들어내야 한다. 앱-티튜드 테스트 - 캔드 백(Ketn Back)은 소프트웨어를 구축하는 세 가지 활동을 다음과 같이 기술했다. 1. "먼저 동작하게 만들어라." 2. "그리고 올바르게 만들어라" 코드를 리펙토링해서 타인이 이해하기 쉽게 만들고, 요구.. 2022. 11. 10.
[책 정리] 28. 테스트 경계 - Clean Architecture - 테스트는 시스템의 일부이며, 아키텍처에도 관여한다. 시스템 컴포넌트인 테스트 - 아키텍처 관점에서는 모든 테스트가 동일하다. TDD 로 생성한 아주 작은 테스트이든, 아니면 대규모의 FitNesse, Cucumber, SpecFlow, JBehave 테스트이든, 이들 테스트는 아키텍처적으로 모두 동등하다. - 테스트는 태생적으로 의존성 규칙을 따른다. 테스트는 세부적이며 구체적인 것으로, 의존성은 항상 테스트 대상이 되는 코드를 향한다. 실제로 테스트는 아키텍처에서 가장 바깥쪽 원으로 생각할 수 있다. 시스템 내부의 어떤 것도 테스트에는 의존하지 않으며, 테스트는 시스템의 컴포넌트를 향해, 항상 원의 안쪽으로 의존한다. - 테스트는 시스템 컴포넌트 중에서 가장 고립되어 있다. 테스트가 시스템 운영에 .. 2022. 11. 9.
[책 정리] 27. '크고 작은 모든' 서비스들 - Clean Architecture - 서비스 지향 아키텍처와 마이크로서비스 아키텍처는 최근에 큰 인기를 끌고 있다. 그 이유는 다음과 같다. 1. 서비스를 사용하면 상호 결합이 철저하게 분리되는 것처럼 보인다. (일부만 맞는 말이다.) 2. 서비스를 사용하면 개발과 배포 독립성을 지원하는 것처럼 보인다. (일부만 맞는 말이다.) 서비스 아키텍처? - 서비스를 사용한다는 것이 본질적으로 아키텍처에 해당하는 것이 아니다. 시스템의 아키텍처는 의존성 규칙을 준수하며 고수준의 정책을 저수준의 세부사항으로부터 분리하는 경계에 의해 정의된다. 단순히 앱의 행위를 분리할 뿐인 서비스라면 값비싼 함수 호출에 불과하며, 아키텍처 관점에서 꼭 중요하다고 볼 수는 없다. 모든 서비스가 반드시 아키텍처 관점에서 중요해야만 한다는 뜻은 아니다. 기능을 프로세스.. 2022. 11. 8.
[책 정리] 26. 메인(Main) 컴포넌트 - Clean Architecture 궁극적인 세부사항 - 메인 컴포넌트는 궁극적인 세부사항으로, 가장 낮은 수준의 정책이다. 메인은 시스템의 초기 진입점이다. 운영체제를 제외하면 어떤 것도 메인에 의존하지 않는다. 메인은 모든 팩토리(Factory)와 전략(Strategy), 그리고 시스템 전반을 담당하는 나머지 기반 설비를 생성한 후, 시스템에서 더 높은 수준을 담당하는 부분으로 제어권을 넘기는 역할을 맡는다. 의존성 주입 프레임워크를 이용해 의존성을 주입하는 일은 바로 이 메인 컴포넌트에서 이루어져야 한다. 메인에 의존성이 일단 주입되고 나면, 메인은 의존성 주입 프레임워크를 상용하지 않고도 일반적인 방식으로 의존성을 분배할 수 있어야 한다. - 요지는 메인은 클린 아키텍처에서 가장 바깥 원에 위치하는, 지저분한 저수준 모듈이라는 점이.. 2022. 11. 7.
[책 정리] 25. 계층과 경계 - Clean Architecture - 시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다. 몇몇 단순한 시스템에서는 이 정도로 충분하다. 하지만 대다수의 시스템에서 컴포넌트의 개수는 이보다 훨씬 많다. 움퍼스 사냥 게임 클린 아키텍처? 흐름 횡단하기 흐름 분리하기 결론 - 아키텍트로서 우리는 아키텍처 경계가 언제 필요한지를 신중하게 파악해내야 한다. 또한 우리는 이러한 경계를 제대로 구현하려면 비용이 많이 든다는 사실도 인지하고 있어야 한다. 이와 동시에 이러한 경계가 무시되었다면 나중에 다시 추가하는 비용이 크다는 사실도 알아야 한다. 포괄적인 테트스 스위트(test suite)가 존재하고 리펙터링으로 단련되었더라도 마찬가지다. - 추상화가 필요하리라고 미리 예측해서는 안 된다. 이것이 바로 YAG.. 2022. 11. 6.
반응형