osoriandomori/playground-spring

spring multi module app

spring 테스트 용, 공유 용 Multi Module Application

• application layer
  • 실제 Application 담당할 layer, 현 mvc, reative, batch + cloud 까지 추가 예정
• domain layer
  • application 에서 쓸 domain 별 기능 분리
  • 로직은 없이 설정 위주로 들어갈 예정이나 공통된 로직의 경우 구현 가능
• etc
  • yaml-importer : domain 의 설정을 읽어주는 yaml integration tool
    • application 에선 최상위 모듈에 implementation project(':etc-yaml-importer') 만 추가시 자동 설정 로드
  • coverage : 테스트코드 coverage with github action

Spec

• domain-maria : RDBMS
• domain-mongo : reactive 전용 예정
• domain-neo4j : 공부용 예정
• domain-kafka : cloud 전용 예정

사전 준비

$ docker-compose up -d

playground-spring's Issues

이미지 공짜업로드용 이슈

ttests

ejb 란 대체 뭐냐

스프링 배치 컨셉과 구현

배치는 왜 필요한가

• 대용량 비 실시간 처리
• 통계, 컨텐츠 컨버팅, 유저 데이터 처리

근데 꼭 스프링 배치 프레임워크를 써야하나

• 그냥 웹서비스 프로젝트에 추가해서 사용하는건 분리를 덜하는 느낌임. 취향차이
• 저는 솔직히 새로운 인스턴스로 파는건 귀찮음. (클라우드환경이면 환영)
  • db network acl 이라도 있다면 더더욱 새 인스턴스 만드는게 너무 귀차늠...
  • 그냥 db 연동하고 운영하던거 있으면 api endpoint 로 파거나 이중화 안한 경우 @scheduled 같은거로 실행하면 될듯

프레임워크?

• 개발자가 시스템에 맞추는거 -> 그만큼 제약이 있으면서 안챙겨도 될 부분이있다.
• 스프링 배치를 쓰면 안챙겨도 되는거 그냥 떠오르는것만
  • 트랜잭션
  • 배치 재가동(saveState) 작업 재시작
  • 처리 결과 로깅
  • 처리 도중 로깅
  • 청크단위로 처리

코드를 봅시다. 어떻게 동작을 하는지

• JobLauncher
• Job
• Step
• ChunkOrientedTasklet
• ChunkProvider
• ChunkProcessor

이사람은 ... 뭐가 틀렸을까? 링크

다른 배치 처리 도구는 없을까

• node => 스프링기준 @scheduled 써서 처리하듯이함. 인스턴스 여러개일 때는 express 로 그냥 개발할지도?
• ETL
• 스파크

몇 년간 쓰면서 개인적으로 느낀 스프링 배치

• 사용자 처리 다하기엔 너무 느린거 같음.
  • chunk 단위로 몇 백만, 천만 처리하려고하면 한 세월 걸림,,
  • 그러나 이 다음은 분산처리 인데 여긴 이제 인프라 돈이 많이 들고 러닝커브가 잇지만 스파크 같은걸 써야함 : 저도 기술 자체는 아직 잘 모름.
• 컨텐츠 처리에는 아주 적절한거 같음. listener 를 통한 로깅이나 등등
• 스프링 배치는 스프링 코드 까서보는거 연습 입문용으로 아주 좋았었음. 잘 만들어진 객체지향 프레임워크

사용법은 공홈가서 보자

• https://docs.spring.io/spring-batch/docs/current/reference/html/index.html

스프링 핵심 원리

왜 이런게 궁금해졌는가..

• 비전공자 친구한테 그냥 서버만드는법, 노드로 서버 띄우고, 외부 데이터 호출(http), 엑셀만들기 15분만 알려줬더니
• 하루지나고 자기가 Dart API 끌어다가 엑셀만드는 서비스를 만드는걸 본 뒤, 호스팅까지.... 직업에 대해 위기감을 느껴서..ㅠ
• 그렇게 밥먹을수 있게 해준 스프링을 나는 얼마나 알고 있는가? 왜 나온건가?

EJB (90년대임)

• 자바진영의 겨울

- 겨울이긴한데 이 때 유우명한 기술들은 많이 나옴. 대표적으로 Hibernate. - 아 이거 ejb 의존성 너무 심하고 느려서 못써먹겠다~~ 하고 로드존슨이 샘플코드를 만들었고, 다른 유명개발자가 오 이거 좋네하면서 만들기 시작한게 2003년 스프링ㅎㅎ

객체지향

• 스프링은 객체지향을 잘 하기위해서 만들어진 프레임워크
• 스프링은 잘 정의된 객체지향으로 만들어져있다.
• 스프링을 잘 뜯어보다보면 객체지향으로 잘 만들어졌다는걸 알 수 있다.
  • CacheManager, TransactionManager 역할, 각 dbms transactionmanager 구현 분리

이걸 잘 지켜야지.. 좋은 객체지향 개발임. 객체지향 5가지원칙 (면접용) : 밥아저씨의 애자일 소프트웨어 선언

• SRP(Single Responsibility Principle): 단일 책임 원칙
  • 책임 == 기능. 그냥 하나 기능만 개발하라는거. 근데 기준이 좀 사람마다 다를수있어서 정답은 없음.
• OCP(Open Closed Priciple): 개방 폐쇄 원칙
  • (코드) 변경엔 닫혀있고, (기능) 확장엔 열려있다. : 개인적으로 한국 개발자 기준 가장 지키기 어려운 원칙 ㅋㅋ 수정을 하지 말라니
  • 인터페이스로 만들고 부품 교체하듯이 갈아껴야 지킬 수 있겠지?
• LSP(Listov Substitution Priciple): 리스코프 치환 원칙
  • 하위 구현 객체 바꿔도, 정상동작해야함. 결국 추상화 얘기
• ISP(Interface Segregation Principle): 인터페이스 분리 원칙
  • 인터페이스 하나에 기능 우겨넣지말고, 잘 분리해라
• DIP(Dependency Inversion Principle): 의존 역전 원칙
  • 클라이언트 코드는 구현클래스에 의존하지말고 인터페이스에 의존해라 -> 그래야 갈아끼기 편하니깐 priavte CacheManager;로 하라고
  • 근데 뭐 살다보면 맨날 지키긴힘듦. 사실 개발할때 그냥 private 클래스의존 끌래스; 하는 경우도 많으니깐.
  • 절대 교체하지 않을 코드라고 확신이 들면 뭐 원칙 어기는하에 써도되는듯 ㅋㅋ

자 그럼 코드를 이제 보면서, 제가 객체지향 5원칙을 잘 지킨 개발을 하고있는지 보시죠

• 결국 이걸 지키려면, IoC 컨테이너가 나올수 밖에 없다!!!
• 530cf7a 부터

Proxy 테스트-이놈이 틀린건 뭘까?