오늘은 프로젝트에 DDD를 도입하며 고민하고 공부했던 적용기를 다뤄보려 한다. 도메인 주도 개발이란DDD(Domain-Driven Design) 또는 도메인 주도 설계라고 부르며 도메인 모델을 중심에 놓고 설계하는 방식을 일컫는다. 도메인이란 무엇일까도메인은 특정 문제 영역을 의미하며, 소프트웨어가 해결하려는 비즈니스 영역을 의미한다. 예를 들어, 이커머스 플랫폼을 개발한다면 이커머스 플랫폼은 개발해야하는 대상이 되고 이를 도메인이라고 한다. 도메인은 또 하위 도메인으로 나눠질수 있는데, 주문, 결제, 배송, 고객 관리 등이 해당 도메인에 포함될 수 있다.   각 하위 도메인은 독립적으로 기능을 제공할 수도 있고, 다른 하위 도메인과 연동하여 기능을 제공하기도 한다. 예를 들어, 카탈로그 도메인은 상품 ..

문제상황 프론트 팀원으로부터 어느 날부터 swagger 접속시 해당 화면이 뜬다는 이슈가 들어왔다. 확인해보니 해당 문제 기존의 ssl 인증서가 만료되어서 발생한 일이었다. 근데 나는 certbot으로 기존에 인증서 만료되기 전 자동 갱신을 구현해두었는데..?   무엇이 문제인지 다시 살펴보도록 하자. ssl 인증서 발급 방법에 따른 자동화 가능 여부certbot 을 이용한 인증서 발급 방법은 아래와 같이 크게 5가지 방법이 존재한다.webserver(--nginx, --apache) 옵션을 통한 인증서 발급webroot(--webroot) 옵션을 이용한 인증서 발급standalone(--standalone) 옵션을 이용한 인증서 발급수동 인증 (--manual) 옵션을 이용한 인증서 발급DNS 인증 (..

Https를 달고 나서부터 프론트 팀원에게 swagger에서 CORS 에러가 발생하기 시작한다는 문의가 들어왔다.  요청을 다시 살펴보니 blocked:mixed-content 라는 Status 코드가 떠있었고, 이는 http https 간 통신이 이루어지면 발생하는 에러였다.   실제로 접속 url은 https://[도메인] 이었고 요청을 전송하는 url은 http://[도메인] 이었다.  위와 같이 프론트 개발자가 원하는대로 url을 선택할 수 있게 하자.  하지만 dev환경과 prod 환경의 도메인이 다르므로 2개의 환경에서 swagger는 각자 자신의 맞는 도메인을 띄워줘야한다.  요구사항1. swagger에서 원하는 url을 선택할 수 있어야한다.2. 각 dev와 prod 도메인으로 swagg..

고민의 시작프론트 팀원이 다음과 같은 이슈를 들고 왔습니다. "LightHouse를 통해 성능 검사를 해봤는데 웹 페이지 리소스가 9.7MB가 나왔어요""로컬에서 build하면 2.7MB인데 차이가 꽤 나네요. 로딩 속도도 더 느린것 같구요"LCP(Largest Contentful Paint) 및 페이지 성능 문제LCP란?LCP는 웹 페이지의 주요 콘텐츠(텍스트, 이미지, 비디오 등)가 사용자 화면에 렌더링되는 시간을 측정하는 지표로, 로딩 성능의 핵심 지표 중 하나를 이야기합니다. 우리의 문제점  Lighthouse로 측정한 결과, 우리의 LCP는 10.99초로 평가되었으며 이는 POOR 등급에 해당했고 개선이 필요해보였습니다. LCP에 영향을 미치는 주요 요소구글에 의하면 LCP 지표에 영향을 미치는..

Sentry는 on premise로 직접 sentry를 띄우면 무료로 팀 계정을 사용할 수 있게 해주는데 이 구축기를 공유해보려한다.도입 배경뽀각 서비스를 운영하면서 기존 에러 추적을 위해서 Sentry를 개발 계정으로 한 명이서 관리를 하고 있었다.무료 계정이다보니 팀원 모두가 사용할 수 없어 불편함이 있어 이를 on premise로 옮기기로 결정! 최소 권장 사양4 CPU Cores16 GB RAM20 GB Free Disk SpaceAWS에서 제공하는 프리티어 사양으로는 돌릴 수 없기 때문에 리눅스 컴에 직접 돌리기로 결정하였다.설치 방법git clone https://github.com/getsentry/self-hosted.gitcd self-hostedsudo ./install.shsudo ..

취준 관리 서비스 뽀각을 개발하면서 Spring REST Docs를 도입해 API 문서 생성을 하고 있었다. REST Docs의 장단점은 명확하다.장점 : 프로덕션 코드에 어노테이션 등이 침투하지 않는다.단점 : 테스트 코드가 성공해야만 문서 생성이 가능하다. 테스트 코드도 강제로 짜고 좋지 뭐.. 하며 호기롭게 시작한 REST Docs 적용은 테스트 코드 지옥에 우리를 빠트렸다..문제점 뽀각에는 노션의 페이지처럼 마크다운 문법으로 글을 작성할 수 있는 카드라는 아이템이 있는데 이를 단건조회하는 테스트 코드이다.API 하나에 미친 듯한 코드 줄의 양이 보이는가..? 이는 JSON 상하차를 해야하는 서비스 초반 우리 개발 속도에 발목을 잡았다. 팩토리 클래스 생성이를 REST Docs 문법에 맞는 테스트 ..

고민의 시작백기선님의 이펙티브 자바 완벽 공략의 “아이템 15. 클래스와 멤버의 접근 권한을 최소화하라”에는😄 : “public, protected 접근 제한자를 가지는 API는 하위호환성을 지키고 싶다면 영원히 관리해야하는 코드가 된다” 라는 말이 나옵니다. 응? 나는 스프링에서 지금까지 모든 클래스를 거의 public으로 박아놨는데…. 라는 생각이 들었습니다.여기서 하위호환성을 지킨다는 것은 버전이 올라갈 수록 이전 jar 파일로 배포해두었던 public으로 노출시킨 나의 코드를 누가 언제 어디서 쓰고 있는지 모르기 때문에 다음버전에서도 쉽게 바꾸지 못한다는 것을 의미합니다. 만약 바꾼다면 클라이언트에서 해당 코드에 해당하는 부분을 모두 바꾸어야하는 문제가 생깁니다. 그리고 말하시길😄 : “정답은..

문제상황spring security에서 filterChain을 설정하면서 "/member/signUp" url에 대한 request는 permitAll()을 해주고 싶었다. 이 과정에서 분명 permitAll()를 해주었지만 401 error가 발생하였고 이를 해결하는 과정을 포스팅한다. 본문String[] allowUrls = {"/", "/swagger-ui/**", "/member/signUp"};@Beanpublic SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .csrf(AbstractHttpConfigurer::disable) .cors(Abstra..