만들면서 배우는 클린 아키텍처

웹 계층: 요청을 받아 도메인 혹은 비즈니스 계층에 있는 서비스로 요청을 보낸다.서비스: 필요한 비즈니스 로직 수행, 도메인 엔티티 상태 조회 또는 변경을 위해 영속성 계층의 컴포넌트 호출계층형 아키텍처는 견고한 아키텍처 패턴이다. 계층을 잘 이해하고 구성한다면 웹 계

의존성 역전하기이번 장에선 대안에 대해 이야기한다. 먼저 단일 책임 원칙(Single Responsibility Principle, SRP)과 의존성 역전 원칙(Dependency Inversion Principle, DIP)에 대해 이야기하는 것으로 시작하자.이 원칙

코드를 보는 것만으로도 어떤 아키텍처인지 파악할 수 있다면 좋지 않을까?이번 장에서는 코드를 구성하는 몇 가지 방법을 살펴보고, 육각형 아키텍처를 직접적으로 반영하는 표현력 있는 패키지 구조를 소개하겠다.새 프로젝트에서 가장 먼저 제대로 만들려고 하는 것은 패키지 구

드디어 앞에서 논의한 아키텍처를 어떻게 실제 코드로 구현할지 살펴보자.한 계좌에서 다른 계좌로 송금하는 유스케이스를 구현해보자. 이를 객체지향적인 방식으로 모델링하는 한 가지 방법은 입금과 출금을 할 수 있는 Account 엔티티를 만들고 출금 계좌에서 돈을 출금해서

오늘날의 애플리케이션은 대부분 웹 인터페이스 같은 것을 제공한다. 웹 브라우저를 통해 상호작용할 수 있는 UI나 다른 시스템에서 우리 애플리케이션으로 호출하는 방식으로 상호작용하는 HTTP API가 여기에 해당한다.우리가 목표로 하는 아키텍처에서 외부 세계와의 모든 커

1장에서는 전통적인 계층형 아키텍처는 결국 모든 것이 영속성 계층에 의존하게 되어 '데이터베이스 주도 설계’가 된다고 이야기했다. 이번 장에서는 이러한 의존성을 역전시키기 위해 영속성 계층을 애플리케이션 계층의 플러그인으로 만드는 방법을 살펴보겠다.그림 6.1은 영속성

이번 장에서는 육각형 아키텍처에서의 테스트 전략에 대해 이야기한다. 아키텍처의 각 요소들을 테스트할 수 있는 테스트 유형에 대해 논의할 것이다.그림 7.1의 테스트 피라미드에 따라 테스트에 관한 이야기를 해보자. 그림 7.1은 몇 개의 테스트와 어떤 종류의 테스트를 목

이 책의 전반부에서는 웹,, 애플리케이션, 도메인, 영속성 계층이 무엇이고, 하나의 유스케이스를 구현하기 위해 각 계층이 어떤 역할을 하는지에 대해 다뤘다.그런데 늘상 겪는 문제인 각 계층의 모델을 매핑하는 것에 대해서는 거의 다루지 않았다. 여러분도 매퍼 구현을 피하

유스케이스, 웹 어댑터, 영속성 어댑터를 구현해봤으니, 이제 이것들을 동작하는 애플리케이션으로 조립할 차례다. 3장에서 이야기했듯이 애플리케이션이 시작될 때 클래스를 인스턴스화하고 묶기 위해서 의존성 주입 메커니즘을 이용한다. 이번 장에서는 평범한 자바로 이를 어떻게

지금까지 아키텍처에 대해서 많은 이야기를 나눴다.하지만 일정 규모 이상의 모든 프로젝트에서는 시간이 지나면서 아키텍처가 서서히 무너지게 된다. 계층 간의 경계가 약화되고, 코드는 점점 테스트하기 어려워지고, 새로운 기능을 구현하는 데 점점 더 많은 시간이 든다.이번 장

의식적으로 지름길 사용하기이번 장의 목표는 잠재적인 지름길에 대한 인식을 높이고 그 영향에 대해 이야기하는 것이다.깨진 창문 이론을 나만의 표현으로 바꿔보면 다음과 같다.어떤 것이 멈춘 것처럼 보이고, 망가져 보이고, 부정적인 형용사를 넣어보자, 혹은 관리되지 않는다고

지금까지 육각형 아키텍처 스타일로 웹 애플리케이션을 만드는 방법을 설명했다. 코드를 구성하는 것부터 지름길을 택하는 것까지 이 아키텍처 스타일이 우리에게 던진 많은 질문에 답했다.어떤 답변들은 전통적인 계층형 아키텍처 스타일에도 적용할 수 있다. 또 어떤 답변들은 이