단방향으로 정의해야 코드의 방향을 파악하기 쉬워진다.
infra, modules folder 만들기
infra는 스프링이나 JPA, 서버파트 라이브러리 등을 참조하도록 바꿈
가급적이면 modules은 infra를 참조하지만, infra는 modules를 참조하지 않도록 할 것
SecurityConfig.java
@Configuration // 일단 메모리에 떠야 하니까 어노테이션 추가해줌
@EnableWebSecurity // 직접 시큐리티 설정을 하겠다는 의미
@RequiredArgsConstructor
public class SecurityConfig extends WebSecurityConfigurerAdapter {
private final UserDetailsService userDetailsService;
private final AccountService accountService; -> private final UserDetailsService userDetailsService;
AccountService 가 UserDetailsService 타입을 구현하는(implements) 것이기 때문이다. 그리고 스프링 시큐리티는 UserDetailsService 를 필요로 하지 우리가 만든 Account 라는 도메인을 알지 못한다.
StudyolleApplicationTests 는 스프링 부트 어플리케이션 만들 때 기본으로 만들어주는 클래스, 필요없으므로 삭제!
account에서 study를 참조하고 있다. 즉 Account 에 들어있는 isManagerOf 라는 메서드가 study를 보고 있다.
Account.java
public boolean isManagerOf(Study study) {
return study.getManagers().contains(this);
}
Account는 Study를 보고 있으므로 어디에 사용되는지 확인 후 삭제해야 한다.
StudyServie.java
private void checkIfManager(Account account, Study study) {
if (!study.isManagedBy(account)) {
throw new AccessDeniedException("해당 기능을 사용할 수 없습니다.");
}
}
Study.java
public boolean isManagedBy(Account account) {
return this.getManagers().contains(account);
}
뒤집어주면 테스트가 잘 작동된다.
제일 중요한 rule!
각각의 모듈간의 순환참조가 없는지 확인해야 한다.
깨진다. Account -> Settings -> Account 순환참조 발생
Settings 구현 중 의아했던 부분 중 하나! Setting 은 사실 다 Account에 가는 것, 다 Account쪽으로 옮겨주자.
출처 : 인프런 백기선님의 스프링과 JPA 기반 웹 애플리케이션 개발