Jaime's 기술 블로그

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 소스 코드는 여기 있습니다. Overview 헥사고날 아키텍처에서의 테스트 전략에 대해 살펴봅니다. 테스트 피라미드 위 그림은 몇 개의, 어떤 종류의 테스트를 목표로 해야 하는지 결정하는 데 도움을 줍니다. 기본적으로 만드는 비용이 적고, 유지보수하기 쉽고, 빨리 실행되고, 안정적인 작은 크기의 테스트들에 대해 높은 커버리지를 유지해야 합니다. 여러 개의 단위와 경계를 결합하는 테스트는 비용이 비싸지고 실행이 느려져 깨지기 쉬워집니다. 테스트 피라미드는 테스트가 비싸질 수록 커버리지를 낮게 잡아야 한다는 것을 보여줍니다. 그렇지 않으면 기능구현보다 테스트 구현에 시간이 더 오래 걸리는 배보다 배꼽이 더 큰 상황이 발생하게 됩니다. 단위 테..

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 소스 코드는 여기 있습니다. Overview 처음 계층적 아키텍처의 문제접을 다룰 때 모든 것이 영속성 계층에 의존하게 되어 데이터베이스 주도 설계가 된다는 점을 다룬 적이 있는데요, 의존성을 역전시키기 위해 영속성 계층을 애플리케이션 계층의 플러그인으로 만드는 방법을 살펴봅니다. 의존성 역전 애플리케이션 서비스에서는 영속성을 사용하기위해 아웃고잉 포트 인터페이스를 호출합니다. 이 포트는 영속성 작업을 수행하고 데이터베이스와 통신할 영속성 어댑터가 구현하게 됩니다. 헥사고날 아키텍처에서 영속성 어댑터는 아웃고잉 어댑터에 해당하므로 애플리케이션 계층에서 호출하고 역방향으로 어댑터가 애플리케이션을 호출할 일이 없습니다. 애플리케이션 서비스가 ..

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 소스 코드는 여기 있습니다. Overview 웹 인터페이스를 제공하는 어댑터의 구현 방법을 살펴봅니다. 의존성 역전 웹 어댑터는 주도하는(driving) 또는 인커밍 어댑터 입니다. 외부로부터 요청을 받아 애플리케이션 코어를 호출합니다. 이 때 제어 흐름은 웹 어댑터에 있는 컨트롤러에서 애플리케이션 계층에 있는 서비스로 흐릅니다. 애플리케이션 계층은 웹 어댑터가 통신할 수 있는 포트 인터페이스인 유스케이스를 제공하고 해당 유스케이스를 구현합니다. 여기 의존성 역전 원칙이 적용된 것을 확인할 수 있습니다. 어댑터와 유스케이스 사이에 인터페이스가 존재하는 이유는 애플리케이션 코어가 외부와 통신할 수 있는 규격이기 때문입니다. 이 포트를 적절하..

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 소스 코드는 여기 있습니다. Overview 앞서 살펴본 내용들을 어떻게 실제 코드로 구현할지 살펴봅니다. 도메인 모델 구현 한 계좌에서 다른 계좌로 송금하는 유스케이스를 구현합니다. 객체지향적으로 모델링하기 위해 입출금을 할 수 있는 Account 엔터티를 만들고, 출금 계좌에서 출금하여 입금 계좌로 입금하도록 하였습니다. package buckpal.domain; @AllArgsConstructor(access = AccessLevel.PRIVATE) public class Account { @Getter private final AccountId id; @Getter private final Money baselineBalance; ..

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. Overview 코드를 구성하는 몇 가지 방법과 헥사고날 아키텍처를 표현하는 패키지 구조를 소개합니다. 프로젝트를 처음 생성할 때 패키지 구조를 먼저 설계하게 되는데, 진행될수록 점점 바빠져서 처음의 원칙을 지키지 않고 서로 규칙 없이 참조하게 되는 경우를 많이 겪어보셨을 것입니다. 지금부터 송금하기 유스케이스에 대해 여러 가지 패키지 구조 예시를 살펴보겠습니다. 계층 구조 첫 번째 접근 방법은 계층 구조를 이용하는 것입니다. app ├── domain │ ├── Account │ ├── AccountRepository │ ├── AccountService │ └── Activity ├── persistence │ └── AccountRe..

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 단일 책임 원칙 이 원칙의 일반적인 해석은 "하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다." 이지만 실제 의도는 "컴포넌트를 변경하는 이유은 오직 하나 뿐이어야 한다." 입니다. 책임을 하나의 일을 한다라기보다는 변경해야 할 이유로 해석해야 하는 것이죠. 아키텍처에서 이것을 어떻게 적용할 수 있을까요? 컴포넌트를 변경할 이유가 오직 하나라면 어떤 이유로 소프트웨어를 변경하더라도 이 컴포넌트에 대해 전혀 신경 쓸 필요가 없습니다. 소프트웨어가 변경되더라도 여전히 기대했던 대로 동작할 것이기 때문입니다. 구현하다보면 위 그림같이 됩니다. A는 다른 여러 컴포넌트에 의존하고있고, E는 의존하는 것이 전혀 없..