본문 바로가기
[책 정리] 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.
[책 정리] 24. 부분적 경계 - Clean Architecture - 아키텍처 경계를 완벽하게 만드는 데는 비용이 많이 든다. 쌍방향의 다형적 Boundary 인터페이스, Input 과 Output 을 위한 데이터 구조를 만들어야 할 뿐만 아니라, 두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로 격리하는 데 필요한 모든 의존성을 관리해야 한다. 이렇게 만들려면 엄청난 노력을 기울여야 하고, 유지하는 데도 또 엄청난 노력이 든다. 마지막 단계를 건너뛰기 - 부분적 경계를 생성하는 방법 하나는 독립적으로 컴파일하고 배포할 수 있는 컴포넌트를 만들기 위한 작업은 모두 수행한 후, 단일 컴포넌트에 그대로 모아만 두는 것이다. 쌍방향 인터페이스도 그 컴포넌트에 있고, 입력, 출력 데이터 구조도 거기에 있으며, 모든 것이 완전히 준비되어 있다. 하지만 이 모두를 단일 .. 2022. 11. 5.
[책 정리] 23. 프레젠터와 험블 객체 - Clean Architecture - 프레젠터(presenter)는 험블 객체(humble object) 패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는 데 도움이 된다. 험블 객체 패턴 - 험블 객체 패턴은 디자인 패턴으로, 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 단위 테스트 작성자가 분리하기 쉽게 하는 방법으로 고안되었다. 행위들을 두 개의 모듈 또는 클래스로 나눈다. 이들 모듈 중 하나가 험블(humble)이다. 가장 기본적인 본질은 남기고, 테스트하기 어려운 행위들을 험블 객체로 옮긴다. 나머지 모듈에는 험블 객체에 속하지 않은, 테스트하기 쉬운 행위를 모두 옮긴다. 험블 객체 패턴을 사용하면 프리젠터(테스트 하기 쉬움)와 뷰(테스트 하기 어려움)라는 서로 다른 클래스로 만들 수 있다. 프레젠터와 뷰 - 뷰는 험블.. 2022. 11. 4.
[책 정리] 22. 클린 아키텍처 - Clean Architecture - 육각형 아키텍처(Hexagonal Architecture), DCI(Data, Context and Interaction), BCE(Boundary-Control Entity) 모두 세부적인 면에서는 다소 차이가 있더라도 그 내용은 상당히 비슷하다. 이들의 목표는 모두 관심사의 분리(separation of concerns)다. 이들 모두 소프트웨어를 계층으로 분리함으로써 관심사의 분리라는 목표를 달성할 수 있었다. 각 아키텍처는 최소한 업무 규칙을 위한 계층 하나와, 사용자와 시스템 인터페이스를 위한 또 다른 계층 하나를 반드시 포함한다. - 이들 아키텍처는 모두 시스템이 다음과 같은 특징을 지니도록 만든다. 프레임워크 독립성 아키텍처는 다양한 기능의 라이브러리를 제공하는 소프트웨어, 즉 프레임워크.. 2022. 11. 3.
[책 정리] 21. 소리치는 아키텍처 - Clean Architecture 아키텍처의 테마 - 아키텍처는 프레임워크에 대한 것이 아니다. (그리고 절대로 그래서도 안 된다.) 아키텍처를 프레임워크로부터 제공받아서는 절대 안 된다. 프레임워크는 사용하는 도구일 뿐, 아키텍처가 준수해야 할 대상이 아니다. 아키텍처를 프레임워크 중심으로 만들어버리면 유스케이스가 중심이 되는 아키텍처는 절대 나올 수 없다. 아키텍처의 목적 - 좋은 아키텍처는 유스케이스를 그 중심에 두기 때문에, 프레임워크나 도구, 환경에 전혀 구애받지 않고 유스케이스를 지원하는 구조를 아무런 문제 없이 기술할 수 있다. - 좋은 소프트웨어 아키텍처는 프레임워크, 데이터베이스, 웹 서버, 그리고 여타 개발 환경 문제나 도구에 대해서는 결정을 미룰 수 있도록 만든다. 하지만 웹은? - 웹은 전달 메커니즘(입출력 장치)이.. 2022. 11. 2.
[책 정리] 20장. 업무 규칙 - Clean Architecture - 앱을 업무 규칙과 플러그인으로 구분하려면 업무 규칙이 실제로 무엇인지를 잘 이해해야 한다. 엄밀하게 말하면 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있는 규칙 또는 절차다. 더 엄밀하게 말하면 컴퓨터상으로 구현했는지와 상관없이, 업무 규칙은 사업적으로 수익을 얻거나 비용을 줄일 수 있어야 한다. 사람이 수동으로 직접 수행하더라도 마찬가지다. 이러한 규칙을 핵심 업무 규칙(Critical Business Rule)이라고 부른다. 핵심 업무 규칙은 보통 데이터를 요구한다. 이러한 데이터를 핵심 업무 데이터(Critical Business Data)라고 부른다. 핵심 규칙과 핵심 데이터는 본질적으로 결합되어 있기 때문에 객체로 만들 좋은 후보가 된다. 이러한 유형의 객체를 엔티티(Entity).. 2022. 11. 1.
반응형