프레임워크
이 구역은 Spring과 그 둘레를 맡는다. 자바 구역이 「내 코드가 어떻게 도나」를 봤다면, 여기는 「내가 안 짠 코드가 내 코드를 어떻게 불러 주나」를 본다.
지금 이 구역에서 끝낸 공부는 하나다.
익힌 것 — main() 한 줄을 8단계로 따라갔다
Study · Spring Boot는 SpringApplication.run() 한 줄이 HTTP 응답 한 번이 되기까지를 여덟 토막으로 잘라, 단계마다 버튼으로 한 스텝씩 넘기며 보는 페이지다.
8단계를 한 번 지나면 다음 질문에 답할 수 있다 — 내가 켜지 않은 설정이 왜 켜져 있나, 주입받은 객체가 왜 내 클래스가 아닌가, 컨트롤러 하나를 여러 요청이 동시에 쓰는데 왜 안 깨지나, 첫 요청만 왜 느린가.
같이 읽는 글
프레임워크가 무엇을 해 주는지 알고 나면, 그 위에서 코드를 어디에 놓을지가 다음 문제다. 그건 코딩 스탠다드가 맡는다.
[Coding Standard] 패키지 구조: 규칙을 컴파일러가 강제하게
지금까지 세운 표준들을 다시 읽어보면 같은 문장이 반복해서 나온다.
도메인 안을 네 겹으로 나눈다
[Coding Standard] Repository 설계 표준: 조회 기술은 하나로 안 끝난다
지금까지 정한 표준들은 Repository의 자리를 정했다. 애그리거트 경계 표준은 “Repository는 애그리거트 루트당 하나”라고 했고, 패키지 구조 표준은 인터페이스는 domain에 public으로, 구현체는 infra에 package-private으로 두라고 했다. DTO...
저장·단건 조회와 동적 검색은 인터페이스를 나눈다
[Coding Standard] 예외 처리 표준: 실패가 나가는 길을 하나로
지금까지 정리한 표준들은 요청이 들어오는 길을 다뤘다. 이 글은 반대 방향, 실패가 나가는 길을 다룬다.
ErrorCode가 실패의 단일 출처다
[Proof] @Transactional은 public 메서드에만 걸리는가 — 반증
Domain 영속화 표준(Domain 객체를 DB에 저장하고 다시 꺼내는 방법을 정한 글이다. 「영속화」는 영속성을 갖게 만든다는 뜻이다)은 트랜잭션 경계를 UseCase 구현 메서드에 두기로 하면서 이렇게 적었다.
Study 4단계의 프록시를 실제로 돌려서 잰 증명
아직 안 한 것
- 트랜잭션 — Study에는 없다. 전파 속성, 프록시 자기 호출, 롤백 규칙
- Security — 필터 체인이
DispatcherServlet앞에 어떻게 붙나 - JPA와 영속성 컨텍스트 — 1차 캐시, 더티 체킹, 플러시 시점
- AOP — Study 4단계는 프록시가 생긴 것만 본다. 포인트컷과 어드바이스는 안 봤다