배치 스케줄러를 사용 했는데,

해당 배치 프로그램은

투표 시작과 종료는 30분 단위로만 설정 할 수 있어

배치서버에서 메인서버로 특정 API를 30분마다 반복해 전송,

메인서버에서 시작/종료 하는 투표의 상태를 변경 해주는 것이었는데

회의를 하다가 문득 "상태" 컬럼이 왜 필요한가? 라는 주제가 나오게 됐다.

사실 로직에서도

시작 시간과 종료 시간만 컬럼에 저장해놓는다면,

상태 라는 개념은 필요가 없는 것이 아니냐 였는데

나는 있어야한다 를 주장하고 있었는데도 불구하고,

코드의 가독성을 제외하고는 사실 필요가 없나? 라고 의문이 들기 시작했다.

로직에서도 대기 / 진행 / 종료 라는 개념만 있으면 되는데

해당하는건 서버 현재시간이 시작시간전 / 시작시간과 종료시간 내 / 종료시간 후

면 그냥 해결이 되는것 아니냐는 문제 였다.

이런문제야 어느 관점으로 보냐의 차이겠지만,

내 입장에서는 상태 컬럼이 존재하는 것이 더 명확하고 추후 유지보수 시

새로운 개발자가 봤을때도 더 직관적이고 빠르게 이해 할 수 있지 않나?

라는 의견

반대의 의견은

개발자의 편의를 위해서 성능에 영향이 갈 수 있는데

데이터베이스의 한 컬럼을 소비 하는 것이

괜찮은 것이냐? 라는 의견이었다.

내가봐도 상태 컬럼이 없다고 해서 문제가 생길만한 기능이 아니어서

어느정도 납득은 됐다.

그래서 결론은

일단 이미 코딩이 어느정도 진행중이었기때문에

추후에 상태 컬럼을 없애는쪽으로 진행..

정답은 없는 거라지만,

참 애매모호 한 문제 인 것 같아 작성 하게 됐다.

왜 Stream이 느린가 -> jvm에서 하는 것이 많다.

왜 for가 빠른가 -> for는 단순 인덱싱이다, 컴파일러가 최적화 시킨다.

근데 왜 stream 씀?

읽기가 편하다! 가독성이 좋다!

스트림 내부 함수 이용하면 로직 작성을 덜해도 된다!

    // CustomUserDetailsServce에서 만든 loadUserByUserName이 실행된다.

    Authentication authentication = authenticationManagerBuilder.getObject().authenticate(authenticationToken);

이 부분에서 오류가 났는데,

커스텀으로 만든 userDetail을 일단 보여주자면

  @Override
  @Transactional
  // 로그인시에 DB에서 유저정보와 권한정보를 가져와서 해당 정보를 기반으로 userdetails.User 객체를 생성해 리턴
  public UserDetails loadUserByUsername(final String username) throws UsernameNotFoundException {

    return customerRepository.findOneWithAuthoritiesByCustomerEmail(username)
        .map(user -> createUser(username, user))
        .orElseThrow(() -> new UsernameNotFoundException(username + " -> 유저를 찾을 수 없습니다."));
  }

  private org.springframework.security.core.userdetails.User createUser(String username, Customer customer) {
    if (!customer.isActivated()) {
      throw new RuntimeException(username + " -> 활성화되어 있지 않습니다.");
    }

    List<GrantedAuthority> grantedAuthorities = customer.getAuthorities()
        .stream()
        .map(authority -> new SimpleGrantedAuthority(authority.getAuthority()))
        .collect(Collectors.toList());

    return new User(customer.getCustomerName(), bCryptPasswordEncoder.encode(customer.getPassword()), grantedAuthorities);
  }
}

loadUserByUsername 메소드를 사용하는데

새로운 유저를 만들어 security context에 넣어주는 과정에서

이미 저 customer 라는 객체를 파라미터로 받을때

내부의 password는 암호화가 되어있었는데

위 코드를 리턴할때 한번더 암호화를 해버렸고 그 결과

.authenticate()메소드를 구현하는

AbstractUserDetailsAuthenticationProvider 라는 추상 클래스에서

additionalAuthenticationChecks() 라는 메소드 안에서 오류가 발생했다.

        if (!this.passwordEncoder.matches(presentedPassword, userDetails.getPassword())) {
            this.logger.debug("Failed to authenticate since password does not match stored value");
            throw new BadCredentialsException(this.messages
                    .getMessage("AbstractUserDetailsAuthenticationProvider.badCredentials", "Bad credentials"));
        }
    }

BcyptEncoder를 통해

userDetail 과 UsernamePasswordAuthenticationToken 의

비밀번호가 매치 하는지 확인하는 와중에 에러가 발생한 것 같다.

해서

  private org.springframework.security.core.userdetails.User createUser(String username, Customer customer) {
    if (!customer.isActivated()) {
      throw new RuntimeException(username + " -> 활성화되어 있지 않습니다.");
    }

    List<GrantedAuthority> grantedAuthorities = customer.getAuthorities()
        .stream()
        .map(authority -> new SimpleGrantedAuthority(authority.getAuthority()))
        .collect(Collectors.toList());

    return new User(customer.getCustomerEmail(), customer.getPassword(), grantedAuthorities);
  }

로 변경해 오류를 해결했다.

정확히 어떻게 왜 언제 쓰는지 모르는 아키텍쳐를

있어보이려고 갖다붙이기 보다 기본 토대를 탄탄히 해보자는 느낌에서

기본적인 mvc2 방식에서 DDD구조에서 쓰이는 파사드 구조만 조금 떼낸뒤

hexagonal 아키텍쳐에 사용되는 application 단을 사용 해봤다

기본적인 구조는 이렇게 되어있다

domain

최상위 계층으로 도메인 이름으로 패키지를 구성한다

controller

도메인 안의 컨트롤러 패키지로 restController를 모아두고,

request Dto 폴더를 내부에 생성에 dto 관리를 한다.

facade

파사드 패턴으로, 파사드 패키지 안에서만 현재 도메인 외 외부 도메인, 서비스와 교류 해 코드 복잡성을 줄인다.

application

application/inport 는 service interface를 만들어 보관한다.

application/outport 는 외부 레포지토리 인터페이스를 보관한다.

application/service/serviceImpl에 해당 도메인 관련된 비즈니스 로직을 구현한다.

external

외부에서 오는 데이터등을 관리한다. repository(db) 포함.

왜?

'추후의 확장성만 고려' 한다면 더 용이한 아키텍처가 많겠지만 일단의 목표는 완성과 배포가 우선이기때문에 비교적 단순한 구조를 채택했다.

facade로 여러서비스가 한곳에 엉켜 가독성이 안좋아지는 부분을 막으려고 facade패키지를 따로 추가함.

(2023-10-18 수정) application단 추가는 reader,store를 들여 오면서 application을 단순히 service라고 표현하기에는 무리가 있다 싶어 변경했다.

service에 '접근'하기때문에 inport(밖에서 안으로 들어온다) service에서 '호출'하기때문에 outport(안에서 외부인자를 호출)

repository를 reader 와 store로 나누고, reader는 셀렉트 관련 쿼리, store는 그외의 쿼리들을 구분하면 서비스에서는 네이밍을 깔끔하게 쓸수 있다.

지금은 그때보다는 조금 더 이해 하게 된 편이다.

사용했을때의 장점은 현재의 내가 이해 하기로서는 의존성을 많은 부분 덜어낼 수 있고,

에러가 발생했을때 비교적 빠르게 찾아낼 수 있으며 유지보수성에 큰 도움을 준다 정도 인 것 같다.

// 여기부터는 현재까지 내가 이해한 내용들을 정리 한 것이다. // 틀린 부분이 있을 수 있으니 혹시나 보시는 분이 있다면 한번 더 찾아보시는 걸 추천..

처음에는 마냥 복잡해 보였는데 직장 동료분의 설명을 듣고 확 와닿았던 것은

adapter 단 과

application 단

domain 단 으로

큰 3가지 단이 있고, 여기에 in,out등이 생기는 구조 인데

이런식으로 보면 가장 편하다.

원래 좀 더 단순한 그림 이었는데
애매한 부분이 있어 동료들에게 물어보다보니 더 복잡해졌다...

보통은 이름이 hexagonal 이라 육각형으로 그리는 경우가 대부분이다.
나같은 경우에는 육각형으로 보면 감을 잡지 못했었는데,
이런식으로 보니 그나마 이해가 갔다.

저 그림에서 포트 인 과 아웃이 위아래로 늘어나면 육각형이 되는 형태 인 것.
내가 '이해하고 사용하는 이유'는 현재로서는 의존성 자체를 꽤많이 줄일수 있는 구조 라는것 정도다.

apdapter in 은 portIn 을 의존하고, portIn은 서비스 기능을 구현한다.

그래서 서비스는 보통 인터페이스로 구성 하고

그래서 어댑터나 포트인 쪽에서 데이터가 꼬이거나 오류가 발생해도 

포트아웃쪽으로는 사이드 이펙트가 전파가 되지않는다.

반대로 

포트아웃이나 어댑터 아웃에서 필드명이 바뀐다거나 

메소드 변경이 생기는 일 이 발생 하더라도,

포트인쪽 까지는 사이드 이펙트가 전파 되지 않는 구조를 지닌다.

지금 일하고 있는 회사에서는
좀 더 DDD 아키텍쳐랑 이것저것 섞어서 보완 해서 쓰긴 했지만

사실 이걸 온전히 내가 이해 하고 쓰고 있냐고 한다면 아직은 부족한 것 같다.

회사에서 베이스로 사용하는 모달 페이지가 있어서 사용하려 했는데

다른 페이지에서 사용 된건 이미 잘 되고 있고,

내가 개발 하려는 페이지서만 모달창이 뜨지 않았다.

웃긴건

개발하는 페이지 (안됨) -> 다른 아무페이지로 이동 -> 개발하는 페이지 로 가면 모달이 작동을 한다..

라우터 문제인가 렌더링이 안된건가 아니면 너무 된건가 찾아보던 와중에

결론만 말하자면 부트스트랩이 import가 안되어 있었다 ㅎㅎ..

다른페이지에 갔다 오면 왜 어떤방식으로 작동되는건지는 알아내지 못했다..

그래서 기존 모달 페이지 내부에 부트스트랩을 import 해주니 전역으로 잘 돌아갔다 ^<^;

import 'bootstrap/js/dist/modal';

아무래도 경험 자체가 좀 적고 실제로 아키텍쳐의 덕을 보거나 "유용했다!" 라는 느낌을

받지 못해서 인것 같다.

요 근래 하고 있는 사이드프로젝트에서 DDD+layout 구조를 쓰고

현재 다니는 회사에서 개발하고 있는 새 프로젝트는 hexagonal 아키텍쳐를 쓰기로 정하고

개발을 하고 있는데 과정이 길어질 뿐더러 request 변수가 하나 바뀌면

이후 command , info 등을 수정하고

관련 비즈니스 로직 도 체크를 해야하니 그저 번거롭고 복잡하다. 정도의 생각인 것 같다.

그나마 이해가 됐던건 의존성을 최대한 줄일 수 있다 정도,,, 그래도 아직 실제로 오픈을 해보고

많은 테스트가 이루어 진게 아닌 초반 설계 단계이다보니 장점을 못본 것 같다.

에러잡을때도 훨씬 편하다고 하니 눈에 안익어도 억지로 봐야겠다는 생각.

배워야할 게 산더미다 아오..

AllArgsConstructor 필드값 다 가진 생성자 만드는 어노테이션

Builder 필요한 필드 값만 따로 가져올수 있게 만드는 어노테이션 순서 안지켜도 됨 직접 만들면 생성자 만든 순서 대로 해야됨 ex) Member.builder().username~.build();

Data 게터 세터 다만들어주는 어노테이션 외에도 여러가지를 만들어주는데 @Data 자체를 추천하지 않는 경우도 있다. 코틀린의 경우는 dataClass 라는게 있어서 자체지원 됨

Getter 게터만 만들어줌 Setter 세터만 만들어줌

패킷 스위칭

데이터를 하나하나 쪼개고 그것을 패킷이라고 함 그걸 한개씩 전송함

패킷스위칭 을쓰면 C라는 사용자가 데이터를 보내도 같은 선을 이용함
받는 서버 쪽에서 각각 사용자의 데이터를 조립함 데이터는 전선을 이용해 들어오는데
패킷 경우엔 3개의 데이터를 보내면 각자가 다른 속도로 누가먼저 도착할지 몰라서 모든 패킷에는 헤더가 붙어있음
헤더에 순서, 보낸 사람이 누군지 식별자가 붙어있어서 정리가능
바디에는 실질적 데이터가 들어가는것 바디 데이터의 타입은 TEXT일수도, 이미지 일수도 AVI일수도있기때문에 MIME타입을 공부해야 설정을 해서 보낼수 있음

서킷 스위칭

A와 B가 데이터를 교환할때 데이터를 한방에 올려서 전송함

속도는 빠르지만 선이 물리적으로 많이 필요함

MIME(마임) 타입 패킷으로 데이터를 보낼때 바디에 들어갈 데이터의 타입 형식이란 뜻 POST요청은 여기에 대한 ~~ 데이터를 추가! 해줘 라는 뜻인데 이걸 어디에 담냐면 요청시에 헤더와 바디 라는 걸 달고 요청을 감

내 사진이 MY.JPEG 라고 치면

헤더에 : IMAGE/JPEG

바디에 : MY.JPEG 가 들어감

바디에는 실질적 데이터

헤더에는 데이터를 설명해주는 내용이 있어야함

Stateless 요청시 마다 스트림을 연결해서 데이터를 주고받는 방식 http 가 이 방식을 씀

Statefull 연결이 지속되있는 방식 (채팅같이 데이터 실시간 연결)

세션을 만들다 = 데이터를 응답해줄 준비가됨 (인증이 됨)

http는 stateless라서 연결이 끊기면 세션을 끊어야되서

이걸 어떻게 유지할 것인가가 중요

2022 / 05 / 10 -> 아직 제대로 된 이해 못 함

2023 / 01 / 27 -> 놀랍게도 지금도 다를바 없는듯 흐릿한 개념만 남아있다 공부 할 것...

클라이언트 = 배고픈 사람 = 요청하는 사람

통신방법 (요청,request) 4가지

get = 데이터를 줘! (Select)

get 방식으로만 인터넷 브라우저를 불러올수 있고 어떤 데이터를 요청할 건지 요청하는 방법은 쿼리스트링 밖에없다 특징 : body로 데이터를 담아 보내지 않음 주소(헤더)에 데이터를 담아서 보내는것 그래서 무슨데이터를 보내는지 다 보임

나머지 3개는 데이터를 변경하는 요청임 - 데이터를 담아보내야 할 것이 많다. - 회원가입만 해도 주르륵 있음

post = 데이터를 추가해 줘! (Insert)
클라이언트가 데이터를 입력(예를 들면 회원가입처럼)해서 던져줌!

put = 데이터를 수정해 줘! (update) -> DB row 전체를 갈아 치우는 것이 때문에 필요한 경우에만 쓰는 것이 베스트~

patch = 데이터를 "일부만" 수정해줘! (update) -> DB row 한줄을 전부 바꾸는 것이 아닌 경우에 쓰면 효율적

delete = 데이터를 지워 줘! (delete)

이걸 더티체킹이라고 함

• 스프링이 heap영역을 제어함 그래서 내가 스택안의 지역변수들을
  매번 만들 필요없이 어노테이션을 붙여서 스프링컨테이너에 인식을 시키면 알아서 스프링이 만들어준다.

IOC를 따르기 위해서 패키지 파일을 ioc 규칙에 맞게 설계해야함

처음에 resultType이나 ParameterType 문제 인 줄 알고 허둥거렸으나

if문으로 걸어놓은 권한에 의한 Join 조건이 문제 였다.

  <if test="group != null and !gruop.equals('manager') and !gruop.equals('secondManager')">
          LEFT OUTER JOIN OtherTable
  ON customerName = OtherTable.customerName
  </if>

이런 비슷한 조건이 붙어 있어서 (아마 만들때 잘 못 들어간 것으로 추정)

내가 쿼리를 보는 상황에서는 if문이 false로 나와서 join 자체가 들어가지 않았고

다른 직원들이 보려하면 true였기때문에 join이 들어가고

하나의 결과만 나와야 하는 쿼리에서 조인으로 여러항목이 불러져와서 만들어진 오류 였다.