'개발(레거시)' 카테고리의 글 목록

kotlin + spring boot 프로젝트에서 DTO 검증 체크리스트

2023.08.04·

개발(레거시)/문제 해결

1. Web 요청 모델과 Service 요청 모델을 분리했는가?spring-boot-starter-validation이 표현 계층 하위에서 필요한지 생각해 보기(domain이나 application...등등에서 불필요함!)data class ReserveProductWebRequest( .... ) { fun mapToServiceRequest(): ReserveProductRequest { return ReserveProductRequest( shopId, products.map { it.mapToServiceObject() }, LocalDateTime.parse(reservedAt) ) } } 2. 중첩해서 검증하고 싶다면? 중첩 DTO의 예시는 다음과 같음 ReserveProductWebReque..

서브 패턴

2023.07.31·

개발(레거시)/정규 표현식 수련관(휴업)

서브 패턴 Page 10 - 작은 괄호 안에 파이프로 문자열 or 효과 Source : Monday Tuesday Friday Case 1 Regular Expression : (on|ues|rida) First match: Monday Tuesday Friday All matches : Monday Tuesday Friday Case 2 Regular Expression : (Mon|Tues|Fri)day First match: Monday Tuesday Friday All matches :Monday Tuesday Friday Case 3 Regular Expression : ..(id|esd|nd)ay First match: Monday Tuesday Friday All matches : Monda..

특정 문자

2023.07.31·

개발(레거시)/정규 표현식 수련관(휴업)

특정 문자 Page 7 - 괄호 중에 하나라도 있나요? [ ] Source : How do you do? Case 1 Regular Expression : [oyu] First match: How do you do? All matches : How do you do? Case 2 Regular Expression : [dH]. First match: How do you do? All matches : How do you do? Case 3 Regular Expression : [owy][yow] First match: How do you do? All matches : How do you do? Inside square brackets "[]" a list of character can be provid..

모든 문자

2023.07.30·

개발(레거시)/정규 표현식 수련관(휴업)

모든 문자 Page 5 - 포인트는 모든 캐릭터를 매칭함! Source : Regular expressions are powerful!! Case 1 Regular Expression : . First match: Regular expressions are powerful!! All matches : Regular expressions are powerful!! Case 2 Regular Expression : ...... First match: Regular expressions are powerful!! All matches : Regula/r expr/ession/s are /powerf/ul!! (6개씩 끊김) Point . matches any character. (일종의 와일드 카드) Page..

위치와 이스케이핑

2023.07.30·

개발(레거시)/정규 표현식 수련관(휴업)

위치와 이스케이핑 Page 3 - 앵커를 사용해 보자! Source : who is who Case 1 Regular Expression : ^who First match: who is who All matches : who is who Case 2 Regular Expression : who$ First match: who is who All matches : who is who ^(캐럿)이 등장하면 캐럿 뒤의 문자가 소스 상에서 시작 위치에 있을 경우 사용됨 $(달러)는 소스의 끝에 위치하는 대상을 지목할 때 사용함 Character ^ matches the beginning of the line(case 1) while dollar sign$ the end of the line(case 2) Pag..

정규 표현식 패턴 기본

2023.07.29·

개발(레거시)/정규 표현식 수련관(휴업)

정규 표현식이란? 특정한 규칙을 가진 문자열의 집합을 표현하는 데 사용하는 형식 언어 형식 언어는 특정한 법칙들에 따라 적절하게 구성된 문자열의 집합 정규 표현식의 가장 기본적인 문법 Page 1 - 정규 표현식은 대소문자를 구분하신다~ Source : Hello, world! Case 1 Regular Expression : Hello First match: Hello, world! All matches : Hello, world! Case 2 Regular Expression : hello First match: Hello, world! All matches : Hello, world! Regular expressions are case sensitive Page2 - 공백 포함한 모든 문자, 중요...

레거시 코드를 헥사고날 아키텍처로 전환(Final) - 회원 도메인에서 웹, 인증 어댑터 분리

2023.04.04·

개발(레거시)/문제 해결

레거시 코드를 헥사고날 아키텍처로 전환(2)과 이어지는 글입니다 1단계, 컨트롤러 패키지 위치 변경 기존에 존재하는 컨트롤러의 위치를 adapter 내부로 이동시켰다. 2단계, 컨트롤러에서 필요한 기존 userService에 대한 의존성 제거 @RequestMapping("/user") @InboundAdapter @RequiredArgsConstructor public class UserController { private final JwtService jwtService; private final RegisterUserUseCase registerUserUseCase; private final UserWithdrawalUseCase userWithdrawalUseCase; private final R..

레거시 코드를 헥사고날 아키텍처로 전환(2) - 회원 도메인에서 읽기 전용 유스 케이스 분리, 영속성 어댑터 만들기

2023.03.31·

개발(레거시)/문제 해결

레거시 코드를 헥사고날 아키텍처로 전환(1)과 이어지는 글입니다. 1단계, 영속성 어댑터를 만들자 영속성 어댑터의 위치는 다음과 같다. 기존에 존재하는 UserRepository를 변경하기 이전에 나는 도메인 엔티티와 JPA 엔티티를 분리하기로 했다. 관련해서 "만들면서 배우는 클린 아키텍처"라는 책에서 다음과 같은 말을 인용해 봤다. 영속성 측면과 타협 없이 풍부한 도메인 모델을 생성하고 싶다면 도메인 모델과 영속성 모델을 매핑하는 것이 좋다. JPA 엔티티에는 기본 생성자가 필요하다. 또한 영속성 레이어에서는 성능 측면에서 @ManyToOne 관계를 설정하는 것이 적합할 수 있지만, 도메인 모델에서는 반대가 되는 것이 더욱 객체지향적일 수 있다. 예를 들어, 팀(야구)이라는 객체가 있다. 4번 타자와..

레거시 코드를 헥사고날 아키텍처로 전환(1) - 회원 도메인에서 쓰기 전용 유스 케이스 분리

2023.03.29·

개발(레거시)/문제 해결

들어가는 말 현재 만들고 있는 사이드 프로젝트인 아르티에서 안 좋은 신호들을 발견했던 걸 정리해 둔 글이 있다. 아르티 아키텍처 디자인에 대해서 끄적에서는 주로 뚱뚱한 서비스 클래스를 어떻게 분리할 것인가에 대해 다룬다. 글을 쓴 이후에도 문제를 해결하기 위해서 여러 글을 찾아봤는데, 이때 헥사고날 아키텍처라는 것을 알게 됐다. 현재 팀원과 나는 "만들면서 배우는 클린 아키텍처"라는 책을 읽고, 프로젝트에 적용 중이다. 이번 주에는 내가 회원 도메인을 개선하기로 맡았는데, 과정을 기록하고 팀원에게 공유하는 것이 포스팅의 목적이다. 이외에도 쿼리나 테스트 코드를 개선하고 싶었는데 이번 기회에 시도해 봐야겠다. (기존 테스트 코드는 모든 스프링 빈을 컨테이너에 담아서 실행하기 때문에 시간이 오래 걸릴뿐더러,..

아르티 리팩터링 기록 - publish

2023.01.23·

개발(레거시)/문제 해결

문제 임시 저장된 전시 기록을 발행(영구 저장)하는 기능이다. exhibit->publication 으로 메시지를 요청하는데, publication#isPublished 을 호출해서 값을 가져와 스스로 판단한다. (Tell Dont Ask 위반) 이로 인해 publication의 캡슐화가 저해된다. 변경

아르티 아키텍처 디자인에 대해서 끄적

2023.01.23·

개발(레거시)/문제 해결

1. 신호 이 고민은 유효성 검사 로직에서 출발한다. 유효성 검사 로직이 많아지다 보니 처음에는 validator class를 분리해야 하나 생각했다. 하지만 그것보다 근본적인 문제가 있었다. 전시 서비스에서 카테고리 서비스를 참조해서 카테고리를 조회해야 하는데 이때 자신이 사용하는 것보다 더욱 많은 기능을 가져오게 된다. 왜 그럴까? 2. 원인과 문제 원인 원인은 서비스 클래스가 너무 많은 일을 하고 있는 것이다. 이는 SRP 위반이라고 할 수 있다. 따라서 서비스 클래스의 길이가 점점 커진다. 문제점 서비스 클래스가 길어지면 기능을 추가할 때마다 코드를 깔끔하게 유지하기 어렵다. 전형적인 뚱뚱한 클래스로 Fan-In 문제가 발생한다. 예컨대 전시 서비스, 카테고리 컨트롤러가 의존함 테스트 코드가 길어..

Intelij Ultimate 다이어그램 안나올 경우

2022.12.11·

개발(레거시)/문제 해결

문제 상황 패키지, 클래스 선택한 이후 ctrl + alt + shift + U, 혹은 우측 마우스 클릭해서 다이어그램이 생성이 안된 상황 문제 해결 ultimate 기준, 기본 번들 플러그인에 diagrams 비활성화인지 체크할 것 ctrl + alt + S diagrams 검색 활성화 체크

JPA 1대N 관계 양방향 매핑 상황별 쿼리 갯수 예측

2022.12.02·

개발(레거시)/JPA

첫 번째 상황 package hellojpa; import javax.persistence.EntityManager; import javax.persistence.EntityManagerFactory; import javax.persistence.EntityTransaction; import javax.persistence.Persistence; import java.util.List; public class JpaMain { public static void main(String[] args) { EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello"); EntityManager em = emf.createEntityManag..

[JPA] N + 1 문제

2022.11.22·

개발(레거시)/JPA

보충 학습 후 재정비가 필요한 글입니다. N + 1 문제란 요청이 1개의 쿼리로 처리 되길 기대했는데, N개의 추가 쿼리가 발생하는 현상이다. N + 1 문제는 즉시 로딩과 지연 로딩 전략 각각의 상황에서 발생할 수 있다. 즉시 로딩에서 N + 1 이 생기는 이유 JPQL이란 Java Persistence Query Language의 약어로, 엔티티 객체를 대상으로 쿼리를 작성할 수 있도록 해준다. 즉시 로딩에서 발생하는 이유는 JPQL을 사용하는 경우 전체 조회를 했을 때, 영속성 콘텍스트가 아닌 데이터베이스에서 직접 데이터를 조회한 다음 즉시 로딩 전략이 동작하기 때문이다. 다시 말하자면, JPQL은 즉시 로딩 쿼리를 만들때, 연관관계가 있는 엔티티는 신경 쓰지 않고, 조회 대상이 되는 엔티티를 기준..

String, String Buffer, String Builder

2022.11.12·

개발(레거시)/자바

1. 시작부터 요약 자바에서 문자열을 다루기 위해서는 크게 String, String Buffer, String Builder를 사용할 수 있다. 들어가기 앞서 요약하자면, 연산이 많지 않을 경우는 아무거나 사용해도 상관없다. 하지만, 멀티 쓰레드 환경이고 문자열 연산이 많다면 String Buffer를 사용하고, 문자열 연산이 많고 쓰레드 동기화를 고려하지 않아도 되는 경우 String Builder를 사용한다. 또한 문자열 연산이 적고, 멀티 쓰레드 환경을 고려해야 한다면 String 클래스를 사용하면 적절하다. 2. 불변(immutable)한 String 클래스 자바의 String 클래스는 불변하다. 위와 같은 예제에서 보이는 것처럼, String 클래스는 기존 문자열에 "Tendulkar"를 더해..

티스토리툴바