이 글을 쓰게된 이유최근 사이드 프로젝트를  시작하면서 패키지 구조 부터 시작해서 모듈간의 분리로 인한 멀티 모듈 공부를 하다 아키텍처에 대해서 공부하다 궁금했던 헥사고날 아키텍처에 까지 공부를 하다보니 이 글 을 쓰게 되었다.(제목은 어그로입니다 죄송합니다 ㅎㅎ;;)실무에서의 헥사고날일단 헥사고날의 간단한 후기는 정말 성숙한 도메인이 이며 프로젝트의 수명이 굉장히 길어질거라는 확신이 있지 않는 이상 실무에는 도입하기가 어려울것 같다 라는 생각이 지금은 든다.(추가해야 할 코드의 양이 너무 많다) 굉장히 실용적으로 보이는 계층형 아키텍처최근 애플리케이션 아키텍처에 대해서 자세히 공부를 하다보니 살짝 동일한 부분이 있는 아키텍처를 발견했다.4 계층 레이어를 주로 사용하는 게 보인다. https://xeou..

저자의 SOLID 원칙의 정확한 의미책에서는 초반에 SOLID 원칙 중 2개를 먼저 애기하고 정확한 의미는 이렇다하고 살짝 수정을 해야하겠다고 말을 한다.나는 이 부분에 굉장히 동의를 했다. 단일 책임 원칙하나의 컴포넌트는 오로지 한 가지 일만 해야 하고, 그것을 올바르게 수행해야 한다.컴포넌트를 변경하는 이유는 오직 하나뿐이어야 한다.책임 -> 변경할 이유단일 책임 원칙 -> 단일 변경 이유 원칙(Single Reason to Change Principal)의존성 역전 원칙도메인 코드는 애플리케이션에서 가장 중요한 코드다. 따라서 의존성을 역전시켜 의존성으로부터 보호(격리)해야 한다.코드상의 어떤 의존성이든 그 방향을 바꿀 수(역전시킬 수) 있다.사실 의존성의 양쪽 코드를 모두 제어할 수 있을 때만 의..

sql 튜닝 대상select type  성능이 좋은 실행계획 SIMPE , PRIMARY , DERIVED 성능이 별로인 실행계획 DEPENDENT * , UNCACHEABLE  TYPE 기준 성능이 좋은 실행계획   system , const  , eq_req 성능이 나쁜 실행계획  index , all extra 기준성능이 좋은 실행계획  Using_Index 성능이 나쁜 실행계획  Using_filesort , Using_temporay    좋은 SQL의 조건 SQL 단순 수정으로 튜닝인덱스 키를 타입에 맞게 사용하자 문자열을 자르거나 하지않고숫자타입을 문자타입으로 형 변환을 하지 않고DATE 타입을 LIKE로 찾거나 하지않고 비교연산자를 사용하자  사용하지 않는 함수를 포함시키는 것을 지양하자N..

이상민님의 자바 성능 튜닝 이야기를 정리한 내용입니다.반드시 튜닝해야 하는 대상은? 시간적 여유가 있고, 모니터링 툴이 있다면 전체 화면을 점검하는 것을 권장하지만, 시간 대비 효율을 따졌을 때 상당히 비효율적인 작업이 될 수도 있다.로그인 및 초기 화면, 가장 많이 사용하는 화면을 위주로 성능을 분석하는 것이 가장 현명한 방법이다.어떤 화면이 많이 쓰이는지 알고 싶다웹 로그란?아파치나 Nginx와 같은 모든 웹 서버에 공통적으로 제공되는 기능이 웹 로그이다.서버에 어떤 사용자가 어떤 요청을 하였고, 결과는 어떠한지 파일에 한 줄씩 쌓아 준다.웹 로그를 사용하면 그 동안 생각지도 못했던 문제점을 찾을 수도 있다. 상용 툴을 사용한다면 실시간으로 데이터를 처리하여 확인할 수도 있을 것이다.튜닝의 절차는 그..

사내에서 Event를 도입을 하면서 Event 예외 상황에 대해서 생각을 하며 구현을 했던 것을 정리하려고 합니다. Event 기술 결정 좋은 Event 기반 기술들이 있는 와중에 러닝커브가 크지 않는 점 과 인프라 에서 의 추가 설치 관리 를 고려하여Spring에서 기본으로 제공하는 EventPublisher을 활용하기로 했습니다. Event 구독 코드예외 처리 코드는 반복 사용 가능해 보이는 템플릿으로 보여졌기에 Custom Annotation(@HandleFailure)을 만들어  AOP 기능을 활용하여 을 만들어서 catch 문을 분리했습니다. @EventListener @HandleFailure @Async public void handleCustomEvent(CustomE..

스프링 부트 통합 테스트 환경에서 MockBean 성능 저하 문제스프링을 사용하는 개발자분들의 대부분은 통합테스트 작성시 @MockBean을 사용하실 것 같습니다.Mock을 사용하고 통합테스트를 진행시 1개라면 괜찮지만 N개일 경우에는 N번 만큼 Spring context가 reload 를 할 것입니다.그 이유는 스프링은 @MockBean 설정이 다르거나, @MockBean이 존재하지 않는다면 다른 구성으로 판단 하기 때문입니다. N번의 reload 이유는  BeanFactory 에서 특정 Bean만 Mocking 객체로 교체하면 되는것이 아니라 해당 Bean을 의존하고 있는 모든 Bean들을 모두 확인 후 교체해서 주입해주어야 하기 때문에 이미 등록된 Context상에서 처리하기에는 어려움이 있는 작업..