phantasmicmeans 기술 블로그

시스템이 세 가지 컴포넌트(UI, 업무 규칙, 데이터베이스)로만 구성된다고 생각하기 쉽다. 몇몇 단순한 시스템에서는 이 정도로 충분하다. 하지만 대다수의 시스템 컴포넌트의 개수는 이보다 훨씬 많다. 움퍼스 사냥 게임 GO EAST, SHOOT WEST와 같은 단순한 명령어를 사용한다. 플레이어는 명령어를 입력하며, 컴퓨터는 플레이어가 보고 듣고 경험한 것들로 응답한다. 텍스트 기반 UI는 유지하되, 게임 규칙과 UI를 분리해서 제품을 여러 시장에서 다양한 언어로 발매한다고 가정해보자. 이 규칙은 언어 독립적인 API로 UI 컴포넌트와 통신할 것이고 UI는 API를 사람이 이해할 수 있는 언어로 변환할 것이다. 소스 코드 의존성을 적절히 관리하면 어떤 언어를 UI가 사용하더라도 게임 규칙을 재사용 할 수 ..

아키텍처 경계를 완벽하게 만드는 데는 상당한 비용이 든다. 쌍방향의 다형적 Boundary 인터페이스, Input과 Output을 위한 데이터 구조를 만들어야 할 뿐만 아니라, 두 영역을 독립적으로 컴파일하고 배포할 수 있는 컴포넌트로 격리하는데 필요한 모든 의존성을 관리해야함. 이렇게 만들려면 엄청난 노력이 필요함. 애자일 커뮤니티에서의 많은 이가 이러한 종류의 선행적 설계를 탐탁치 않게 여김 YAGNI(You Aren't Going to Need IT) 원칙을 위배하기 때문. 하지만 아키텍트라면 이 문제를 검토하면서 "어쩌면 필요할 지도" 라는 생각이 들 수 있다. 그렇다면 부분적 경계(partial boundary)를 구현해볼 수 있다. 마지막 단계를 건너뛰기 독립적으로 컴파일하고 배포할 수 있는 ..

프레젠터는 험블 객체 패턴을 따른 형태로, 아키텍처 경계를 식별하고 보호하는 데 도움이 된다. 22장 '클린 아키텍처'는 험블 객체 구현체들로 가득 차 있다. 험블 객체 패턴 테스트하기 어려운 행위와 테스트하기 쉬운 행위를 분리하기 쉽게 가장 기본적인 본질은 남기고, 테스트하기 어려운 객체를 험블 객체로 옮김. 나머지 모듈에는 험블 객체에 속하지 않는, 테스트하기 쉬운 행위를 모두 옮긴다. GUI의 경우 단위 테스트가 어려움 화면을 보면서 각 요소가 필요한 위치에 적절히 표시 되었는지 검사하는 테스트는 작성하기 매우 어렵다. 하지만 GUI에서 수행하는 행위의 대다수는 쉽게 테스트할 수 있다. 험블 객체 패턴을 사용하면 두 부류의 행위를 분리해 프레젠터와 뷰 라는 서로 다른 클래스로 만들 수 있다. 프레젠..

ADP: 의존성 비순환 원칙 하향식(top-down) 설계 SDP & SAP ADP: 의존성 비순환 원칙 컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안된다 숙취 증후군 동일한 소스 파일을 수정하는 환경에서 발생. 누군가가 마지막으로 수정한 코드 때문에 정상 동작하지 않음 주 단위 빌드(Weekly build) 한 주의 첫 4일은 알아서 코딩하고 마지막 날 몰아서 통합 결국 통합 이슈를 겪게 되고 효율성 저하 순환 의존성 제거하기 개발 환경을 릴리즈 가능한 컴포넌트 단위로 분리하는 것 개발자가 해당 컴포넌트가 동작하도록 만든 후, 해당 컴포넌트를 릴리스하여 다른 개발자가 사용할 수 있도록 함 해당 컴포넌트를 사용하는 개발자들은 릴리즈 된 버전을 사용, 새 릴리즈를 사용은 각 팀에서 알아서 판단 ..

Key Point 안정된 추상에 의존시키며 구체에 의존 X 소스 코듸 의존성과 제어 흐름은 반대로 -> 이 원칙이 의존성 역전 DIP 의존성 역전 원칙에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템 자바와 같은 정적 타입 언어에서 이 말은 import 구문이 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야한다는 뜻 구체적인 대상에 절대로 의존해서는 안됨 이러한 아이디어를 규칙으로 보기에는 비현실적 측면이 있음 Java String 구체 클래스 그 예시로 자바의 String은 구체 클래스이며, 이를 추상 클래스로 만드려는 시도는 현실성이 없음. 이 경우 구체 클래스에 대한 의존성은 벗어날 수 없고, 벗어나서도 안됨 String은 매우..

먼저 expectNext / assertNext / consumeNextWith (아래에서 설명할 thenConsumeWhile와 비교를 위해 간단히 추가 했습니다.) 가장 기본적인 연산자로는 expectNext / assertNext / consumeNextWith가 있습니다. 모두 결국 onNext signal을 기반으로 동작합니다만, 이 연산자들은 아이템이 emit 되지 않으면 에러를 발생시킵니다. 즉, empty publisher를 차단할 수 있습니다. (empty publisher 반환을 테스트하고 싶다면 아래와 같은 방법을 사용하거나 아래에서 설명할 thenConsumeWhile을 사용하면 됩니다.) @Test public void EMPTY_PUBLISHER_TEST() { Mono mono..

Key Points 불필요한 짐을 실은 무언가에 의존하면 예상치 못한 문제에 빠질 수 있다. ISP: 인터페이스 분리 원칙 인터페이스 분리 원칙은 아래 다이어그램에서 이름이 유래됨 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용하고 각 유저들은 각자 다른 하나의 오퍼레이션만 사용한다. User1 -> op1 User2 -> op2 User3 -> op3 정적 타입 언어인 경우 User1이 op2,op3를 전혀 사용하지 않음에도 User1의 소스 코드는 이 두 메서드에 의존하게 됨 이러한 의존성으로 인해 OPS 클래스에서 op2 코드가 변경되면 User1도 다시 컴파일 해야함 따라서 아래처럼 변경 오퍼레이션 분리 인터페이스를 두고 오퍼레이션을 분리 User1 -> U10ps(op1) 에는 의존하지만 OP..

Key Point 안정된 추상에 의존시키며 구체에 의존 X 소스 코드 의존성과 제어 흐름은 반대로 -> 이 원칙이 의존성 역전 DIP 의존성 역전 원칙에서 말하는 유연성이 극대화된 시스템이란 소스 코드 의존성이 추상에 의존하며 구체에는 의존하지 않는 시스템 자바와 같은 정적 타입 언어에서 이 말은 import 구문이 오직 인터페이스나 추상 클래스 같은 추상적인 선언만을 참조해야한다는 뜻 구체적인 대상에 절대로 의존해서는 안됨 이러한 아이디어를 규칙으로 보기에는 비현실적 측면이 있음 Java String 구체 클래스 그 예시로 자바의 String은 구체 클래스이며, 이를 추상 클래스로 만드려는 시도는 현실성이 없음. 이 경우 구체 클래스에 대한 의존성은 벗어날 수 없고, 벗어나서도 안됨 String은 매우..

Key Point 함수형 프로그래밍에서의 변수 상태에 초점 함수형 언어에서 변수는 변경되지 않는다 함수형 프로그래밍은 변수 할당에 부과되는 규율이다. Functional Programming 정의 함수형 프로그래밍은 순수 함수로 나누어 문제를 해결하는 기법, 작은 문제를 해결하기 위한 함수를 작성하고 사용 자료 처리를 수학적 함수의 계산으로 취급하고 상태와 가변 데이터를 멀리하는 프로그래밍 패러다임의 하나 명령형 프로그래밍에서는 상태를 변경하는 것을 강조하는것과 달리, 함수형 프로그래밍은 함수의 응용을 강조한다. Side Effect가 없는 Pure Function을 1급객체로 Pure Function 설명 Side effect가 없는 함수 (함수의 실행이 외부에 영향을 끼치지 않는 함수, thread-..

코틀린의 가장 큰 장점중에 하나인 Extension Function 구글링해보면 이 주제에 관련된 자료는 무궁무진하고.. 솔직히 내용이 쉬워서 아래 자료를 보고 이해하면 될 것 같다. https://medium.com/til-kotlin-ko/kotlin%EC%9D%98-extension%EC%9D%80-%EC%96%B4%EB%96%BB%EA%B2%8C-%EB%8F%99%EC%9E%91%ED%95%98%EB%8A%94%EA%B0%80-part-1-7badafa7524a https://codechacha.com/ko/kotlin-extension-functions/ https://dev.to/frevib/kotlin-extension-function-vs-function-literal-with-receiv..