배경 어떤 구성원의 프로필 사진을 조회할 수 있는 API가 있다. 해당 API는 구성원의 프로필 사진 URL을 구해서, 302 응답을 내려준다. (Location 헤더에 프로필 사진 URL) 해당 API는 Authorization 헤더를 참조해 인증/인가 작업을 거친다. 프로필 사진 URL에 접근할 때도 Authorization 헤더가 필요하다. 프로필 사진 조회 API와 프로필 사진 URL의 호스트는 다르다. API를 호출해보니 리다이렉트는 되었지만 프로필 사진 URL 조회 시에 인증 실패가 발생한다. 원인 Postman이나 curl 명령어 등 대부분의 HTTP 클라이언트에서는 다른 호스트로 리다이렉트 될 때 Authorization 헤더는 유지하지 않고 요청을 보낸다....

상속 관계 매핑 관계형 데이터베이스에는 객체지향 언어에서 다루는 상속이라는 개념이 없다. 슈퍼타입 서브타입 논리 모델을 실제 물리 모델인 테이블로 구현하는 방법 3가지 조인 전략: 모두 테이블로 만들고 조회할 때 조인을 사용한다. 단일 테이블 전략: 테이블을 하나만 사용해서 통합한다. 구현 클래스마다 테이블 전략: 서브 타입마다 하나의 테이블을 만든다. 조인 전략 엔티티 각각을 모두 테이블로 만들고 자식 테이블이 부모 테이블의 기본 키를 받아서 기본 키 + 외래 키로 사용하는 전략 주의 점: 타입을 구분하기 위한 컬럼이 추가 되어야 한다....

쿠버네티스 이해하기 쿠버네티스는 컨테이너 오케스트레이션을 위한 솔루션이다. 오케스트레이션: 복잡한 단계를 관리하고 요소들의 유기적인 관계를 미리 정의해 손쉽게 사용하도록 서비스를 제공하는 것 다수의 컨테이너를 유기적으로 연결, 실행, 종료할 뿐만 아니라 상태를 추적하고 보존하는 등 컨테이너를 안정적으로 사용할 수 있게 만들어준다. 쿠버네티스 구성 요소 간 통신 마스터 노드 kubectl: 쿠버네티스 클러스터에 명령을 내리는 역할을 한다. 다른 구성 요소들과 다르게 바로 실행되는 멍령 형태인 바이너리로 배포되기 때문에 마스터 노드에 있을 필요는 없지만, 통상적으로 API 서버와 주로 통신하므로 이 책에서는 API 서버가 위치한 마스터 노드에 구성했다....

경계와 의존성 가장 안쪽 계층에는 도메인 엔티티가 있다. 애플리케이션 계층은 애프리케이션 서비스 안에 유스케이스를 구현하기 위해 도메인 엔티티에 접근한다. 어댑터는 인커밍 포트를 통해 서비스에 접근하고, 반대로 서비스는 아웃고잉 포트를 통해 어댑터에 접근한다. 설정 계층은 어댑터와 서비스 객체를 생성할 팩터리를 포함하고 있고, 의존성 주입 메커니즘을 제공한다. 접근 제한자 package-private 제한자: 패키지 내에 있는 클래스들은 서로 접근 가능하지만, 패키지 바깥에서는 접근할 수 없다. 모듈의 진입점으로 활용될 클래스들만 골라서 public으로 만들면, 의존성이 잘못된 방향을 가리켜서 의존성 규칙을 위반할 위험이 줄어든다....

왜 지름길은 깨진 창문 같을까? 품질이 떨어진 코드에서 작업할 때 더 낮은 품질의 코드를 추가하기가 쉽다. 코딩 규칙을 많이 어긴 코드에서 작업할 때 또 다른 규칙을 어기기도 쉽다. 지름길을 많이 사용한 코드에서 작업할 때 또 다른 지름길을 추가하기도 쉽다. 유스케이스 간 모델 공유하기 유스케이스마다 다른 입출력 모델을 가져야 한다. 유스케이스가 입출력 모델을 공유하는 것은 단일 책임 원칙에서 이야기하는 ‘변경할 이유’를 공유하는 것이다. 유스케이스 간 입출력 모델을 공유한느 것은 유스케이스들이 기능적으로 묶여 있을 때 유요하다....

왜 조립까지 신경 써야 할까? 아키텍처에 대해 중립적이고 인스턴스 생성을 위해 모든 클래스에대한 의존성을 가지는 설정 컴포넌트(configuration component)가 있어야 한다. 이유: 코드 의존성이 올바른 방향을 가리키게 하기 위해 부수효과: 클래스가 필요로 하는 모든 객체를 생성자로 전달 수 있다면 실제 객체 대신 목으로 전달할 수 있고, 이렇게 되면 격리된 단위 테스트를 생성하기 쉬워진다. 설정 컴포넌트의 역할: 우리가 제공한 조각들로 애플리케이션을 조립 설정 파일이나 커맨드라인 파라미터 등과 같은 설정 파라미터의 소스에도 접근할 수 있어야 한다....

애노테이션 선언과 적용 애노테이션 적용 코틀린에서 @Deprecated 애노테이션은 대신할 수 있는 패턴을 제시할 수 있다. @Deprecated("Use new(index) instead.", ReplaceWith("new(index)")) fun deprecated(index: Int) { println("deprecated: index") } fun new(index: Int) { println("new: $index") } 애노테이션의 인자로는 원시 타입의 값, 문자열, enum, 클래스 참조, 다른 애노테이션 클래스, 그리고 지금까지 말한 요소들로 이뤄진 배열이 들어갈 수 있다. 클래스 애노테이션 인자로 지정할 때는 @MyAnnotation(MyClass::class) 처럼 ::class를 클래스 이름 뒤에 넣어야 한다. 다른 애노테이션을 인자로 지정할 때는 인자로 들어가는 애노테이션의 이름 앞에 @를 넣지 말아야된다....

테스트 피라미드 단위 테스트: 피라미드의 토대 일반적으로 하나의 클래스를 인스턴스화하고 해당 클래스의 인터페이스를 통해 기능들을 테스트한다. 만약 테스트 중인 클래스가 다른 클래스에 의존한다면 의존되는 클래스들은 인스턴스화하지 않고 테스트하는 동안 필요한 작업들을 흉내 내는 목으로 대체한다. 통합 테스트: 여러 유닛을 인스턴스화하고 시작점이 되는 클래스의 인터페이스로 데이터를 보낸 후 유닛들의 네트워크가 기대한대로 잘 동작하는지 검증한다. 이 책에서 정의한 통합 테스트에서는 두 계층 간의 경계를 걸쳐서 테스트할 수 있기 때문에 객체 네트워크가 와넞ㄴ하지 않거나 어떤 시점에는 목을 대상으로 수행해야 한다....

의존성 역전 영속성 어댑터의 책임 영속성 어댑터가 하는 일 입력을 받는다. 입력을 데이터베이스 포맷으로 매핑한다. 입력을 데이터베이스로 보낸다. 데이터베이스 출력을 애플리케이션 포맷으로 매핑한다. 출력을 반환한다. JPA를 사용하는 경우에는 입력 모델을 JPA 엔티티 객체로 매핑할 것이다. 맥락에 따라서 입력 모델을 JPA 엔티티로 매핑하는 것이 들이는 노력에 비해 얻는 것이 많지 않은 일이될 수 있으므로 매핑하지 않는 전략도 존재한다. 영속성 어댑터의 입력 모델은 애플리케이션 코어에 있기 때문에 영속성 어댑터 내부를 변경하는 것이 코어에 영향을 미치지 않는다....

의존성 역전 인커밍 어댑터는 애플리케이션 서비스에 의해 구현된 인터페이스인 전용 포트를 통해 애플케이션 계층과 통신한다. 어댑터와 유스케이스 사이에 간접 계층을 넣어야 되는 이유 포트: 애플리케이션 코어와 외부 세계와 통신할 수 있는 곳에 대한 명세이다. 포트를 적절한 곳에 위치시키면 외부와 어떤 통신이 일어나고 있는지 정확히 알 수 있다. 웹 소켓의 경우 웹 어댑터에서 아웃고잉 포트를 구현하고 애플리케이션 코어에서 호출해야 한다. 웹 어댑터의 책임 웹 어댑터가 일반적으로 하는 일 HTTP 요청을 자바 객체로 매핑 권한 검색 입력 유효성 검증 입력을 유스케이스의 입력 모델로 매핑 유스케이스 호출 유스케이스의 출력을 HTTP로 매핑 HTTP 응답을 반환 유스 케이스 입력 모델의 검증과 차이점 웹 어댑터 입력 모델과 유스 케이스 입력 모델에는 차이가 있을 수 있으므로 또 다른 검증을 수행해야 한다....

엔티티 연관관계를 매핑할 때는 3가지를 고려해야 한다. 다중성 다대일 일대다 일대일 다대다 단방향, 양방향 객체 관계에서 한 쪽만 참조하는 것을 단방향 관계, 양쪽이 서로 참조한느 것을 양방향 관계라 한다. 연관관계의 주인 두 객체의 연관관계 중에서 외래 키를 관리하는 객체를 연관관계의 주인이라 한다. 외래 키를 가진 테이블과 매핑한 엔티티가 외래 키를 관리하는 게 효율적이므로 보통 이곳을 연관관계의 주인으로 선택한다. 다대일 일대다 또는 다대일 관계에서 외래 키는 항상 다쪽에 있다. 따라서 객체 양방향 관계에서 연관관계의 주인은 항상 다쪽이다....

컬럼의 데이터 타입과 길이를 선정할 때 가장 주의할 사항은 다음과 같다. 저장되는 값의 성격에 맞는 최적의 타입을 선정 가변 길이 컬럼은 최적의 길이를 지정 조인 조건으로 사용되는 컬럼은 똑같은 데이터 타입으로 선정 문자열(CHAR와 VARCHAR) 저장 공간 CHAR와 VARCHAR의 공통점은 문자열을 저장할 수 있는 데이터 타입이라는 점이고, 가장 큰 차이는 고정 길이냐 가변 길이냐다. CHAR(1)과 VARCHAR(1) 타입을 사용할 때 사용되는 저장 공간의 크기 두 문자열 타입 모두 한 글자를 저장할 때 사용하는 문자 집합에 따라 실제 저장 공간은 1~4바이트까지 사용된다....

방향 단방향: 객체의 한 쪽만 참조하는 것 양방향: 객체가 서로 참조하는 것 다중성: N:1, 1:N, 1:1, N:M 연관관계 주인: 객체를 양방향 영관관계로 만들면 연관관계의 주인을 정해야 한다. 단방향 연관관계 객체는 참조(주소)로 연관관계를 맺는다. 테이블은 외래 키로 연관관계를 맺는다. 참조를 사용하는 객체의 연관관계는 단방향이다. A -> B (a.b) 외래 키를 사용하는 테이블의 연관관계는 양방향이다. A JOIN B가 가능하면 반대로 B JOIN A 도 가능하다. 객체를 양방향으로 참조하려면 단방향 연관관계를 2개 만들어야 한다....

용어 정리 produce: 메시지를 보내는 행위. 메시지를 보내는 프로그램을 producer라고 한다. consume: 메시지를 받는 행위. 메시지를 받는 프로그램을 consumer라고 한다. queue: 큰 메시지 버퍼. 호스트의 메모리 및 디스크에 의해 제한될 수 있다. 많은 프로듀서가 하나의 큐에 메시지를 보낼 수도 있고, 많은 컨슈머가 하나의 큐에서 받을 수도 있다. 하나의 프로그램이 프로듀서이자 컨슈머 일 수도 있다. Java Client 사용해보기 종속성 추가 <dependency> <groupId>com.rabbitmq</groupId> <artifactId>amqp-client</artifactId> <version>5.16.0</version> </dependency> Producer Connection: 소켓 커넥션의 추상화 Connection과 Channel은 Autoclosable의 구현체 channel....

계층으로 구성하기 buckapl |--- domain | |----- Account | |----- Activity | |----- AccountRepository | |----- AccountService |--- persistence | |----- AccountRepositoryImpl |--- web | |----- AccountController domain 패키지에 AccountRepository 인터페이스를 추가하고, persistence 패키지에 AccountRepositoryImpl 구현체를 둠으로써 의존성을 역전시켰다. 위 패키지 구조가 최적이 아닌 이유 애플리케이션의 기능 조각이나 특성을 구분 짓는 패키지 경계가 없다. 애플리케이션이 어떤 유스케이스들을 제공하는지 파악할 수 없다. 패키지 구조를 통해서는 우리가 목표로하는 육각형 아키텍처를 파악하기 어렵다. 기능으로 구성하기 buckpal |-- account |-- Account |-- AccountController |-- AccountRepository |-- AccountRepositoryImpl |-- SendMoneyService 패키지 경계를 package-private 접근 수준과 결합하면 각 기능 사이의 불필요한 의존성을 방지할 수 있다....

배경 통합 테스트에서 WebTestClient를 사용하고 있는데 응답 바디 assertion에서 내부적으로 JsonPath 방식으로 응답 바디의 경로를 지정해 검증하고 있다. 좀 더 유연한 테스트 코드 작성을 위해 JsonPath 표현식 작성법을 이해한다. 표기법 JsonPath 표현식에는 2가지의 표기법이 존재한다. 점 표기법: $.players[0].nickname 괄호 표기법: $['players'][0]['nickname'] 연산자 연산자 설명 $ 루트 노드 @ 처리하고 있는 현재 노드 * 와일드카드. 숫자나 이름이 필요한 모든 곳에서 사용 가능하다. .. Deep scan. 이름이 필요한 모든 곳에서 사용 가능하다. ....

앤티티 매니저(Entity Manager)는 엔티티를 저장하고, 수정하고, 삭제하고, 조회하는 등 엔티티와 관련된 모든 일을 처리한다. 개발자 입장에서 엔티티 매니저는 엔티티를 저장하는 가상의 데이터베이스로 생각하면 된다. 엔티티 매니저 팩토리와 엔티티 매니저 데이터베이스 하나만 사용하는 애플리케이션은 일반적으로 EntityManagerFactory를 하나만 생성한다. 엔티티 매니저 팩토리는 엔티티 매니저를 만드는 공장인데 ,공장을 만드는 비용은 상당히 크다. 따라서 한 개만 만들어서 애플리케이션 전체에서 공유하도록 설계되어 있다. 엔티티 매니저 팩토리는 여러 스레드가 동시에 접근해도 안전하므로 서로 다른 스레드 간에 공유해도 되지만, 엔티티 매니저는 여러 스레드가 동시에 접근하면 동시성 문제가 발생하므로 스레드 간에 절대 공유하면 안 된다....

단일 책임 원칙 오해의 소지가 있는 해석: 하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다. 올바른 해석: 컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다. 변경할 이유라는 것은 컴포넌트 간의 의존성을 통해 쉽게 전파된다. 어떤 컴포넌트의 의존성 각각은 이 컴포넌트를 변경하는 이유 하나씩에 해당한다. 단일 책임 원칙을 위반하면 시간이 갈수록 변경하기 어려워지고 그로 인해 변경 비용도 증가한다. 부수효과에 관한 이야기 잘못 구조화된 소프트웨어를 변경하는 데는 부수 효과로 인해 더 많은 비용을 지불하도록 만드는 경우가 많다....

객체 매핑 시작 CREATE TABLE MEMBER ( ID VARCHAR(255) NOT NULL, NAME VARCHAR(255), AGE INTEGER, PRIMARY KEY(ID) ) @Entity @Table(name = "MEMBER") class Member( @Id @Column(name = "ID") var id: String, @Column(name = "NAME") var username: String, var age: Int, ) @Entity: 이 클래스를 테이블과 매핑된다고 JPA에게 알려준다. @Table: 엔티티 클래스에 매핑할 테이블 정보를 알려준다. name 속성을 사용해 Member엔티티를 MEMBER 테이블에 매핑했다. @Id: 엔티티 클래스의 필드를 테이블의 기본 키에 매핑한다. @Column: 필드를 컬럼에 매핑한다....

SQL을 직접 다룰 때 발생하는 문제점 반복, 반복 그리고 반복 객체를 데이터베이스에 CRUD하려면 너무 많은 SQL과 JDBC API를 코드로 작성해야 한다. SQL 작성 JDBC API를 사용해서 SQL 실행 SQL과 객체의 매핑 테이블마다 이런 일을 반복해야 해서 작성해야 된다. SQL에 의존적인 개발 Member 객체에 새로운 필드 Team을 추가할 경우 클래스에 필드 추가 CRUD 쿼리 수정 연관 관계 매핑을 위한 JOIN 쿼리가 있는 새로운 DAO 메소드 추가 Member 객체는 team 필드가 있는지 확인하기 위해 DAO를 열어서 SQL을 확인할 수 밖에 없다....