소개 만들면서 배우는 클린 아키텍처 책을 읽고 정리하며 소감을 적는 포스트입니다. 애플리케이션 조립하기 유스케이스, 웹 어댑터, 영속성 어댑터를 구현해봤으니, 이제 이것들을 동작하는 애플리케이션으로 조립하는 차례이다. 왜 조립까지 신경 써야 할까? 필요할때 마다 인스턴스화 시켜서 사용하지 않는 것은 의존성이 올바른 방향을 가리키게 하기 위해서다. 애플리케이션의 도메인 코드 방향으로 향해야 도메인 코드가 바깥 계층의 변경으로부터 안전하다. 유스케이스가 영속성 어댑처를 호출해야 하고 스스로 인스턴스화한다면 코드 의존성이 잘못된 방향으로 만들어진 것이다. 그럼 객체 인스턴스를 생성할 책임은 누구에게 있을까?? 중립적인 설정 컴포넌트는 인스턴스 생성을 위해 모든 클래스에 접근할 수 있다. 위 그림과 같이 아키텍..

소개 만들면서 배우는 클린 아키텍처 책을 읽고 정리하며 소감을 적는 포스트입니다. 경계 간 매핑하기 늘상 겪는 문제인 각 계층의 모델을 매핑하는 것에 대해서는 거의 다뤄지지 않는다. 여러분도 매퍼 구현을 피하기 위해 두 계층에서 같은 모델을 사용하는 것에 대해 논의 해 본적이 있을 것이다. 매핑에 찬성하는 개발자 : 두 계층 간에 매핑을 하지 않으면 양 계층에서 같은 모델을 사용해야 하는데 이렇게 하면 두 계층이 강하게 결합됩니다. 매핑에 반대하는 개발자 : 하지만 두 계층 간에 매핑을 하게 되면 보일러플레이트 코드를 너무 많이 만들게 돼요. 많은 유스케이스들이 오직 CRUD만 수행하고 계층에 걸쳐 같은 모델을 사용하기 때문에 계층 사이의 매핑은 과합니다. 모두 틀린 말이 아니며 결정에 도움이 되는 매핑..

소개 만들면서 배우는 클린 아키텍처 책을 읽고 정리하며 소감을 적는 포스트입니다. 아키텍처 요소 테스트하기 많은 프로젝트의 자동화된 테스트는 규칙에 따라 작성되지만 테스트 전략을 물었을 때 제대로 답변하는 이가 없었다. 이번 포스트에서는 육각형 아키텍처에서의 테스트 전략에 대해 이야기 합니다. 테스트 피라미드 테스트 피라미드에 따르면 비용이 많이 드는 테스트는 지양하고 비용이 적게 드는 테스트를 많이 만들어야 한다. 기본 전제는 만드는 비용이 적고, 유지보수하기 쉽고, 빨리 실행되고, 안정적인 작은 크기의 테스트들에 대해 높은 커버리지를 유지해야 한다. 단위와 단위를 넘는 경계, 아키텍처의 경계, 시스템의 경계를 결합하는 테스트는 만드는 비용이 더 비싸지고, 실행이 더 느려지며 깨지기 쉬워진다. 단위 테..

소개 만들면서 배우는 클린 아키텍처 책을 읽고 정리하며 소감을 적는 포스트입니다. 영속성 어댑터 구현하기 전통적인 계층형 아키텍처의 경우 영속성 계층에 의존하게 되어 데이터베이스 주도 설계가 된다고 이야기 했었다. 이번 포스트에서는 이러한 의존성을 역전시키기 위해 영속성 계층을 애플리케이션 계층의 플러그인으로 만드는 방법에 대해 살펴본다. 의존성 역전 코어의 서비스가 영속성 어댑터에 접근하기 위해 포트를 사용한다. 애플리케이션 서비스에서 영속성 기능을 사용하기 위해 포트 인터페이스를 호출한다. 그리고 실제 영속성 작업을 수행하고 데이터베이스와 통신할 책임을 가진 영속성 어댑터 클래스에 의해 구현된다. 포트는 사실상 애플리케이션 서비스와 영속성 코드 사이의 간접적인 계층이다. 영속성 문제에 신경 쓰지 않고..

소개 만들면서 배우는 클린 아키텍처 책을 읽고 정리하며 소감을 적는 포스트입니다. 웹 어댑터 구현하기 UI나 다른 시스템에서 애플리케이션을 호출하는 방식으로 상호작용하는 HTTP API가 웹 어댑터에 해당 됩니다. 의존성 역전 아래의 그림은 웹 어댑터와 관련된 아키텍처 요소(어댑터 자체와 애플리케이션 코어와 상호작용 하는 포트)에 조금 더 초점을 맞춘 그림이다. 인커밍 어댑터는 애플리케이션 서비스에 의해 구현된 인터페이스인 전용 포트를 통해 애플리케이션 계층과 통신한다. adapter.in.web은 주도하는 어댑터이다. 제어 흐름은 웹 어댑터에 있는 컨트롤러에서 애플리케이션 계층에 있는 서비스로 흐른다. 애플리케이션 계층은 웹 어댑터가 통신할 수 있는 특정 포트를 제공한다. 위 그림은 의존성 역전 원칙이..

소개 만들면서 배우는 클린 아키텍처 책을 읽고 정리하며 소감을 적는 포스트입니다. 유스케이스 구현하기 이전 포스트에서 만든 육각형 아키텍처에서 애플리케이션, 웹, 영속성 계층이 현재 아키텍처에서 아주 느슨하게 결합돼 있기 때문에 필요한 대로 도메인 코드를 자유롭게 모델링할 수 있다. DDD를 할 수 있고, 풍부하거나(rich), 빈약한(anemic) 도메인 모델을 구현할 수도 있다. 도메인 모델 구현하기 한 계좌에서 다른 계좌로 송금하는 유스케이스를 구현해 본다. 입금과 출금을 할 수 있는 Account 엔티티를 만들고 출금 계좌에서 돈을 출금해서 입금 계좌로 돈을 입금하는 것이다. package buckpal.account.domain; @AllArgsConstructor(access = AccessL..