본문 바로가기

분류 전체보기223

CQRS(Command and Query Responsibility Segregation) 맛보기 - 이론편 안녕하세요. 오늘은 CQRS 패턴이란 무엇이고 어떻게 구현하며 이 패턴으로 시스템을 개발하였을 때 어떠한 장점과 단점을 가지는지에 대해서 알아보는 시간을 가져보도록 하겠습니다. DDD와 CQRS CQRS란 무엇인가에 대해서 이야기 하기전에 앞서서 우리는 먼저 DDD에 대해서 이야기를 할 필요가 있습니다. 간단히게 DDD에 대해서 설명하고 넘어가도록 하겠습니다. DDD는 Domain Driven Design의 약자로 어플리케이션을 비즈니스 Domain별로 나누어 설계 및 개발을 진행하는 개발 방법론입니다. 여기서 Domain은 비즈니스를 말합니다. 그리고 DDD에서는 비즈니스 중심으로 개발하면서 비즈니스에 매핑되는 도메인 모델을 가지게 되는데 이는 비즈니스 자체를 추상화한 설계도로써 도메인 서비스의 중심으.. 2022. 6. 16.
[kotlin] 코틀린 차곡차곡 - 17. require와 check 안녕하세요. 오늘은 오랫만에 코틀린 차곡차곡 시리즈로 찾아왔습니다. 오늘 여러분들께 공유 드릴 내용은 코틀린에서 validation에 대해서 이미 정해져 있는 코드들에 대한 내용입니다. 기존의 validation asis 메서드를 원하는 바로 정확하게 실행시키기 위해서는 실제 본연의 메서드 로직을 실행시키기전에 validation으로 input으로 들어오는 파라미터의 값이나 사용하는 상태 적절한지에 대한 판단이 필요합니다. 이러한 validation은 보통 아래의 2가지로 나눌 수 있습니다. 파라미터 값 자체에 대한 validation 파라미터 값에 의한 기존 Entity를 비롯한 도메인이 가지고 있는 상태에 대한 validation 이러한 valitaion을 구현한다고 하면 기존에는 아래의 코드처럼 일.. 2022. 6. 5.
[kotlin] 레거시(legacy) 코드 리팩토링하기 3편 - 리팩토링 진행하기 1편 : 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 2편 : 레거시(legacy) 코드 리팩토링하기 2편 - 리팩토링 진행하기 안녕하세요. 레거시를 리팩토링하는 3번째 시간입니다. 오늘은 이전 포스팅에서 만들어둔 라인커버리지 100%의 테스트코드에 대한 신뢰를 바탕으로 코드가 좋은 가독성을 가지는 방향으로 리펙토링을 실제로 진행해보고자 합니다. 환경 환경은 이전 시간과 마찬가지로 아래와 같습니다. 기본적인 테스트 프레임워크는 JUnit5를 사용하며 mockking을 위해서 Unit 테스트 라이브러리인 mockk를 추가로 사용합니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-t.. 2022. 5. 16.
[intellij] http를 통해서 E2E(local, server) 테스트를 진행해봅시다 안녕하세요. 많은 분들이 postman을 이용하여 local 테스트를 진행하는 것으로 알고 있습니다. 그런데 사실 intellij 내부에서도 local 테스트를 지원한다는 사실을 알고 있으셨나요? http 파일을 이용하면 intellij에서 local 테스트와 같은 E2E 테스트를 진행할 수 있는데요. 이는 개발이 정상적으로 이루어졌는지 확인하는데 큰 도움이 됩니다. intellij에서 개발하고 intellij에서 테스트 할 수 있다는 것은 좀 더 편하게 개발을 할 수 있다는 뜻인데요. 오늘은 이렇게 개발을 좀 더 생산성 있게 진행하기 위해서 intellij에서 제공하는 http 파일을 이용하여 local 테스트를 진행해보도록 하겠습니다. http 파일 생성 가장 먼저 http 파일을 생성해 보도록 하겠.. 2022. 5. 5.
[kotlin] 레거시(legacy) 코드 리팩토링하기 2편 - 라인커버리지 100% 달성하기 안녕하세요. 오늘은 [kotlin] 레거시(legacy) 코드 리팩토링하기 1편에 이어서 테스트를 통해 실제로 라인커버리지를 100% 달성해보는 포스팅을 진행해보고자 합니다. 이전 편은 테스트 코드를 작성해야 하는 이유에 대해서 설명했습니다. 관심있으신 분들은 한번 보시는것을 추천드립니다. 환경 이번 포스팅과 다음 포스팅에 진행되는 test 환경에는 JUnit5와 코틀린 mock에 주로 사용하는 mockk 라이브러리를 이용하였습니다. build.gradle.kts의 implementation는 아래와 같이 선언하였습니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-test") { exclude(group = "or.. 2022. 4. 23.
[React] Backend 개발자가 admin을 만들기 위해 하는 react 정리 1편 - component와 props, 그리고 props.children 안녕하세요. 오늘은 React로 admin 개발을 하면서 공부했던 React를 사용하기 위해서 배웠던 내용을 정리하려고 합니다. 같은 방법에 대해서 고민하셨던 부분이 있으셨다면 이 포스팅으로 해결하셨으면 좋겠습니다. 아마 아주 기초적인 부분들이 주를 이룰것으로 보이기때문에.. 적절히 걸러서 보시는게 좋을 수 있습니다. :) 오늘 정리할 내용은 react에서 component들 사이에 데이터 전달의 기본이 되는 props와 event에 대해서입니다. component(컴포넌트)와 데이터 전달 React에서 Component는 UI를 이루는 HTML을 반환하는 작은 단위입니다. Component는 한번 만들면 원하는 곳에서 재사용하는 것이 가능합니다. Java에서의 class 또는 메서드라고 생각하시면됩니다.. 2022. 4. 22.
[kotlin] 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 안녕하세요. 서비스의 시간이 오래되면 레거시 코드에 대해 고민이 생기기 마련입니다. 특히 이제는 퇴사한 사람이 남기고간 장황하고 이유를 알 수 없는 코드에 수정이 필요하게 되면 덜컥 겁이나기 시작합니다. 그런 코드들은 생성된 시간이 오래되면 오래될수록 공포감도 커지고 건들고 싶지 않아집니다. 하지만 그렇다고 수정을 안할수도 없습니다. 무작정 수정하게되면 실수 등에 의해서 잘 되던게 오히려 잘못 동작할수도 있습니다. 때문에 우리는 수정하기에 앞서 어느정도 안전장치를 만들어둘 필요가 있습니다. 그것이 바로 테스트 코드를 작성하는 것입니다. 오늘은 레거시 코드에 테스트 코드를 작성하고 커버리지를 올리는 방법에 대해서 알아보는 시간을 가져보도록 하겠습니다. 레거시 코드에 유닛 테스트 코드를 추가하면서 얻을 수 .. 2022. 4. 16.
[JPA] Spring JPA 환경에서 bulk insert를 효율적으로 해보자 - JPA의 한계와 JDBC 활용 안녕하세요. 오늘은 Spring JPA 환경에서 bulk insert를 효율적으로 하는 방법에 대해서 알아보는 시간을 가져보도록 하겠습니다. JPA를 사용하고 ID를 전략을 사용했을 때 JPA의 성능 문제는 이전에 [JPA] JPA의 AUTO_INCREMENT 테이블에서 다건 insert 시간 비교 - save vs saveAll 포스팅에서 간단히 다룬적이 있습니다. 해당 포스팅의 주된 내용은 save와 saveAll의 성능 시간 비교였지만 연관이 있으므로 관심있으신 분들은 해당 포스팅을 일부 참고하셔도 좋을 것 같습니다. Spring Data JPA의 bulk insert와 그 한계점 bulk insert는 한번의 쿼리로 여러건의 데이터 row를 insert할 수 있는 insert 방법입니다. batc.. 2022. 4. 12.
[주절주절] 회사 블로그를 써보았습니다. 안녕하세요. 오랫만에 포스팅으로 인사드립니다. 요즘 회사일과 개인 공부에 좀 집중하느라 포스팅을 올리지 못하고 있었네요 ! 죄송스럽게 생각합니다. m(_ _)m 이와는 별개로 올 3월 초에 현재 다니고 있는 회사의 블로그에 글을 투고하였고 해당 포스팅이 업로드가 되었습니다. 내용은 레거시 API를 개선하는 과정을 담고 있습니다. 시간 괜찮으시면 한번씩 읽어주시면 좋을거 같아요 :) 하쿠나 입장 API 개선하기 - 괴물 API 리팩토링과 성능개선하기 느낀점 회사를 대표해서 올라가는 포스팅중 하나이기 때문에 역시 들어가는 시간이 상당했습니다. 제 개인 블로그 1편을 작성하는데 평균 4시간정도 걸립니다. 회사 블로그는 이의 3배정도인 12시간 정도가 소모되었습니다. 관련된 자료를 모으고 잘못된 정보는 없는지 .. 2022. 4. 4.
[CSS] react를 공부하며 나왔던 CSS 정리 회사에 Admin 만들일이 있어서 react로 개발하게 되었습니다. 그런데 저는 web 관련해서는 거의 전무한 지식을 가지고 있습니다. 그래서 요즘 조금씩 react 공부를하는데 기초가 너무 없으니 배워야할게 많다는걸 느끼고 있습니다. 가장 문제가 되었던게 css에 대해서 지금까지 피해왔던 부분이었습니다. 해당 포스팅에서는 이번에 react를 공부하면서 보았던 css에 대한 기본과 새롭게 배운점을 정리를 해보고자합니다. CSS란 CSS는 Style sheet 언어로 실제 프로그래밍 언어는 아닙니다. HTML 문서에 있는 DOM과 같은 Element들에게 선택적으로 스타일을 적용할 수 있는 언어입니다. 단독으로 사용할수는 없고 HTML과 함께 사용해야합니다. CSS RuleSet body { margin:.. 2022. 3. 19.
[Spring] problem spring web을 이용해보자 - webFlux 적용편 안녕하세요. 이전 시간의 포스팅에서 problem spring web을 Spring MVC에 적용하는 시간을 가져보았습니다. 오늘은 이를 webflux에 적용해보는 시간을 가져보도록 하겠습니다. Spring WebFlux 의존성 problem spring web을 사용하기 위해서는 아래의 의존성이 필요합니다. Spring Web과 전체적인 이름은 유사하지만 동일하지는 않기 때문에 주의하시기 바랍니다. implements("org.zalando:problem-spring-webflux:0.26.2") 환경설정(Configuration) 의존성을 넣어주었으면 이제 환경설정을 해볼 차례입니다. 환경설정은 problemModule에 대한 설정과 json으로 응답값을 만들어 낼때의 mapper를 변경하는 설정이 .. 2022. 3. 6.
[Spring] problem spring web을 이용해 Exception Hadling을 단순화해보자 - MVC 편 안녕하세요. 오늘은 spring에서의 exception handling을 쉽게 사용할 수 있게하는 problem-spring-web 라이브러리를 사용해 보도록 하겠습니다. 오늘 포스팅에서는 Web MVC와 Webflux를 모두 알아보도록 하겠습니다. application/problem+json 알고 있으셨나요 ? 저는 몰랐습니다. http 에러 응답을 json으로 상세하게 반환하는 별도의 Http MediaType이 존재하는 사실을. 이 MediaType의 이름은 application/problem+json입니다. application/problem+json 스키마의 설명은 아래와 같습니다. 새로운 오류 응답 형식을 정의할 필요를 피하기 위해 RFC에서 정한 규약중 하나입니다. 무조건 이런 규약을 따라야.. 2022. 2. 26.