Jaime's 기술 블로그

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 소스 코드는 여기 있습니다. Overview 여태까지 다루지 않은 매핑에 대한 문제를 다룹니다. 매퍼 구현을 피하기 위해 두 계층에서 같은 모델을 사용하는 것에 대한 논쟁이 있습니다. 두 계층 간 매핑을 하지 않으면 두 계층에서 같은 모델을 사용해야 하는데 이렇게 하면 두 계층이 강력하게 결합하게 됩니다. 반면에 두 계층 간 매핑을 따로 하게 되면 보일러플레이트 코드가 너무 많이 늘어나게 됩니다. 대부분 유스케이스들이 CRUD 작업만 수행하는 경우 계층 간에도 같은 모델을 사용하는 경우가 많아 계층 사이의 매핑이 의미가 없을 수도 있습니다. 각 매핑 전략에 따른 장단점을 알아보도록 하겠습니다. 매핑하지 않기 전략 송금하기 유스케이스를 그림..

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 소스 코드는 여기 있습니다. 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; ..

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

이 포스팅은 만들면서 배우는 클린 아키텍처를 읽고 작성하였습니다. 개요 계층으로 구성된 전통적인 웹 애플리케이션 구조는 보통 아래 그림과 같습니다. 웹 계층에서는 요청을 받아 도메인(또는 비즈니스) 계층에 있는 서비스로 요청을 전달하고, 서비스에서 비즈니스 로직을 수행한 뒤, 도메인 Entity의 상태를 조회하거나 변경하기 위해 영속성 계층의 컴포넌트를 호출합니다. 계층형 아키텍처는 견고하고, 잘 이해한다면 독립적으로 도메인 로직을 작성할 수 있으며, 도메인 로직에 영향을 주지 않고 웹 계층과 영속성 계층을 변경할 수 있습니다. 잘 만들어진 아키텍처는 요구사항의 변화에 유연하고 외부 요인에 빠르게 적응할 수 있게 해줍니다. 반면 계층형 아키텍처는 코드에 나쁜 습관이 생기기 쉽고 시간이 지날수록 점점 더 ..