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

만들면서 배우는 클린 아키텍처를 요약한 글입니다.낮은 개발 비용으로 유연하고 적응이 쉬운 소프트웨어 아키텍처 구축하고자 한다.불합리한 기한과 쉬워보이는 지름길은 이러한 아키텍처를 구축하는 것을 매우 어렵게 만든다.전통적인 계층형 아키텍처(layered architect

웹 → 도메인 → 영속성아래 방향으로 접근 가능하다.웹 계층: 요청을 받아 서비스로 요청을 보낸다. 도메인/비즈니스 계층:필요한 비즈니스 로직을 수행영속성 계층: 도메인 엔티티의 현재 상태를 조회하거나 변경하기 위해 컴포넌트 호출계층을 잘 이해하고 구성한다면 웹/영속성

02. 의존성 역전하기 게층형 아키텍처 단점에 대한 대안 단일 책임 원칙 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다. 라는 해석보다는 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. 에 더 가깝다. 책임 ⇒ 변경할

03. 코드 구성하기

육각형 아키텍처는 도메인 중심의 아키텍처에 적합하므로 도메인 엔티티를 만든 후 유스케이스를 구현한다.송금하기 예제Account 엔티티: 실제 계좌의 현재 스냅샷. 입금과 출금을 할 수 있다.Account.baselineBalance 필드: Account.activity

어댑터 = 외부 세계와의 소통 창구웹 어댑터 = 웹 인터페이스제어 흐름: adapter.in.web.Controller → application.service.Service호출adapter.in.web.Controller →(직접 호출) application.servi

전통적인 계층형 아키텍처 → 데이터베이스 주도 설계육각형 아키텍처 → 의존성을 역전시켜 영속성 계층을 애플리케이션 계층의 플러그인으로 작동application.service.Service →(호출) application.port.out.OutgoingPort ←(구현)

육각형 아키텍처의 각 요소 테스트 전략과 유형만드는 비용이 적고, 유지보수하기 쉽고, 빨리 실행되고, 안정적인 작은 크기의 테스트들에 대해 높은 커버리지를 유지해야 한다. = 단위 테스트테스트가 비싸질수록 테스트 커버리지 목표는 낮게 잡아야 한다.기능 구현보다 테스트가

각 계층의 모델을 매핑하는 방법매핑에 찬성양 계층에서 같은 모델을 사용하게 되면 두 계층이 강하게 결합된다.매핑에 반대보일러플레이트 코드: 상용구 코드 또는 단순히 상용구는 거의 또는 전혀 변형 없이 여러 위치에서 반복되는 코드 섹션많은 유스케이스가 CRUD만 수행하고

각각 구현한 유스케이스, 웹 어댑터, 영속성 어댑터를 동작하는 애플리케이션으로 조립하기평범한 자바스프링스프링 부트 프레임워크유스케이스와 어댑터를 필요할 때마다 인스턴스화한다면? 의존성이 여러 방향으로 퍼질 수도 있다.모든 의존성이 애플리케이션 코어(도메인 코드)쪽인 올

아키텍처: 코드를 어떻게 작성하고 어디에 위치시켜야 하는가일정 규모 이상이 되면 아키텍처는 서서히 무너지고, 계층 간 경계가 약화되고, 테스트하기 어려워지고, 새로운 기능을 구현하는 데 더 많은 시간이 든다.접근 제한자컴파일 후 체크빌드 아티팩트= 의존성이 올바른(안쪽

지름길을 피하기 위해서는 지름길 자체를 파악해야 한다.유스케이스 간 모델 공유하기도메인 엔티티를 입출력 모델로 사용하기인커밍 포트 건너뛰기애플리케이션 서비스 건너뛰기깨진 유리창 하나를 방치해 두면, 그 지점을 중심으로 범죄가 확산되기 시작한다품질이 떨어진 코드에서 작업

언제 어느 상황에서 육각형 아키텍처 혹은 전통적인 계층형 아키텍처 스타일을 적용해야 할까?도메인 코드가 애플리케이션에서 가장 중요한가?다른 아키텍처 스타일을 경험해보기외부의 영향을 받지 않고 도메인 코드를 자유롭게 발전시킬 수 있다는 것은 육각형 아키텍처 스타일이 내세