회사에서 개발하는 방식에 익숙해지다보면 점점 아키텍처를 바라보는 관점이 온전히 익숙한 방식을 따라 가게 되는 것 같아서 계층형 아키텍처에 대한 개인적인 생각을 한번 더 정리해보려고 한다. Fat Service 지양하기객체지향원칙을 따르며 계층형 아키텍처로 시스템을 구성할 때, 서비스가 복잡해지면 복잡해질수록 고민해야할 부분들이 많아진다. 나는 보통 구성할 때 presentation, application, domain, infrastructure로 나누곤 하는데,여기서 application(service) 과 domain 은 DDD 관점에서 도메인 레이어라고 볼 수 있다.예를 들어, MemberService를 만들고 그 안에 회원가입, 이메일 변경, 휴면 계정 전환 등 member와 관련된 모든 서비스 ..

NEXTERS 동아리에 참여하며 NCP를 처음으로 사용해보게 되었다.https://github.com/Nexters/goalpanzi-backend GitHub - Nexters/goalpanzi-backendContribute to Nexters/goalpanzi-backend development by creating an account on GitHub.github.com  친구와 함께 경쟁하는 목표 달성 앱 [미션메이트] 를 출시하면서 사용한 서비스는 다음과 같다.- Object Storage : 이미지 저장- Server(VPC) : 서버- Container Registry : docker image 저장소 (CD 파이프라인 연동)- Cloud Insight : 모니터링 * 관리형 DB (Clo..

이직첫 회사에서 인턴을 포함해 약 2년간의 근무를 마치고 새로운 회사로 이직을 하게 되었다.  백엔드 개발자로 커리어를 시작하게 해준 첫 회사였고 자유로운 조직 문화와 좋은 팀원들이 있었기에 즐겁게 다닌 회사였다.  인턴을 하며 부족한 게 많은 상태에서 시작했지만 일단 시작하고 부딪치며 부족한 부분을 빠르게 채우고 팀에 도움이 되기 위해 노력했다.  다른 사람보다 이해 속도가 빠르지 않고 무엇이든 경험해보면서 직접 느끼고 배우는게 많은 편이라 하나 하나의 경험이 전부 소중했다.  지금 생각해보면 부족한 부분이 드러나지 않도록 개인적으로 꾸준히 공부하고 적극적으로 업무에 임했던게 많은 도움이 된 것 같다.   길지 않은 시간 함께했음에도 불구하고 자신의 일처럼 축하해주고 새로운 출발을 응원해준 팀원들에게 ..

웹 브라우저에서 서버로 데이터를 요청할 때, 캐시가 없을 경우 데이터가 변경되지 않았더라도 네트워크를 통해 데이터를 다운로드 받아야 한다. 캐시를 사용하면 불필요한 네트워크 통신 없이 좀 더 빠른 사용자 경험을 할 수 있다. 브라우저 캐시를 적용하는 방법 1. cache-control 적용 - response header에 캐시가 유효한 시간(초)를 함께 반환해 브라우저가 해당 시간동안 캐시로 응답 결과를 저장하도록 한다. - 캐시 시간이 초과되면 다시 네트워크로 요청을 보내 응답을 가져오고 다시 유효시간동안 캐시로 저장하게 된다. (갱신) - 브라우저는 cache-control 정보를 받으면 설정된 시간동안 새로운 요청이 와도 리소스를 요청하지 않는다. - 클라이언트의 메모리 캐시 -> 디스크 캐시 순..

RabbitMQ란 AMQP(MQ 오픈소스 표준 프로토콜)의 구현체 중 하나이자 미들웨어 브로커다. MSA 구조에서 서버와 서버 간 데이터 교환이 필요할 때 주로 사용하며 직접 통신이 아닌 MQ를 거쳐 통신함으로써 서비스 간 결합도를 낮추고 신뢰성 있는 통신을 하고자 할 때 주로 사용한다. kafka에 비해 비교적 적용이 쉬운 편이며 회사에서도 대규모의 이벤트 처리를 해야하는 구조가 아니어서 rabbitMQ를 사용중이다. AMQP의 구성 요소 Exchange : Publisher로부터 수신한 메시지를 큐에 분배하는 라우터 역할 (쉽게 말하면 배달원) Queue : 메시지를 메모리나 디스크에 저장했다가 컨슈머에게 메시지를 전달하는 역할 Binding : Exchange와 Queue의 관계를 정의 구현체인 R..

Spring WebFlux가 큰 틀에서 어떤 방식으로 동작하는지 알아보고자 한다. Spring MVC 의 경우에는 DispatcherServlet 기반으로 요청을 받아 뒷단의 처리가 이루어진다. Spring WebFlux의 경우에도 DispatcherServlet과 같이 front controller 의 역할을 해주는 친구가 존재한다. 일단 결론부터 말하면 대충 분석해본 것들을 요약했을 때 아래 같은 그림이다. (간단하게 표현해서 생략이 많을 수 있다.) DispatcherHandler (WebHandler의 구현체) DispatcherHandler 는 WebHandler 인터페이스의 구현체로 Spring Webflux에서의 front controller 역할을 한다. 아래는 DispatchHandler..

Spring Data 란? Spring 프레임워크의 하위 프로젝트 중 하나로 모델을 기반으로 다양한 데이터 접근 기술을 지원한다. Repository 인터페이스를 통해 객체 매핑을 추상화 형태로 지원하기 때문에 좀 더 쉽게 데이터에 접근 및 사용이 가능하다. Main Module Spring Data Commons : 모든 Spring Module을 뒷받침하는 핵심 Spring 개념 CrudRepository, PagingAndSortingRepository Spring Data JDBC : spring-jdbc에 대한 Spring Data 추상화를 제공하는 모듈 CrudRepository를 구현하는 SimpleJdbcRepository 클래스 Spring Data JPA : JPA를 위한 스프링 데이터..

코틀린은 프로퍼티 위임 이라는 기능을 제공한다. 프로퍼티 위임을 사용하면 일반적인 프로퍼티의 행위를 추출해서 재사용할 수 있다. Observable 데이터의 변경이 있을 때 변경을 감지하여 callback으로 원하는 처리를 할 수 있다. Delegates.observable 함수를 보면 2개의 인자를 받으며 초기값과 데이터 변경이 있을 때 호출되는 콜백 함수 (onChange) 로 이우러져있다. public inline fun observable(initialValue: T, crossinline onChange: (property: KProperty, oldValue: T, newValue: T) -> Unit): ReadWriteProperty = object : ObservableProperty(i..

MDC 란? MDC 는 Mapped Diagnostic Context 의 약자로 key와 value를 저장하는 Map 형식으로 slf4j, logback, log4j 등 로깅 프레임워크에서 필요한 정보를 저장하고 싶을 때 사용한다. ThreadLocal 을 기반으로 컨텍스트 정보를 저장하기 때문에 멀티 쓰레드 환경에서 유용하게 사용이 가능하다. (멀티 쓰레드 환경에서는 로그 메시지에 각 쓰레드에 대한 로그가 섞이기 때문) 요청이 어떤 사용자로부터 들어온 것인지 저장하거나 요청별로 식별자를 만들어 특정 요청에 대한 로그만 추적할 수 있다. 참고: 로그시스템 #4-MDC를 이용하여 쓰레드별로 로그 분류하기 MDC 적용하기 Spring Framework를 사용하고 있다면 AOP를 이용해 쉽게 적용이 가능하다...

Step2 https://github.com/next-step/kotlin-blackjack/pull/528 Test Double 단위 테스트를 위해 의존성 주입 부분에 테스트 더블을 사용해 테스트를 좀 더 편리하게 할 수 있도록 구현하였다. 다만, 피드백을 받으며 Stub, Mock, Fake 등 테스트 더블의 종류에 대해 명확히 알고 사용하는게 좋을 것 같아 정리해보려 한다. Dummy 동작하지 않아도 테스트에는 영향을 미치지 않는 객체를 Dummy 객체라고 한다. 단순 인스턴스화한 객체를 의미한다. Stub 테스트에서 호출된 요청에 대해 미리 준비해둔 결과를 제공한다. 즉, 테스트를 위해 미리 만들어놓은 객체만을 반환한다. (객체의 상태를 검증할 때 주로 사용한다.) Mock 호출에 대한 기대를 명..

미션을 진행하며 받았던 피드백을 토대로 배운 점들을 적어보려 한다. 클린코드 뿐만 아니라 코틀린을 좀 더 코틀린스럽게 구현할 수 있는 방법들을 많이 알아갈 수 있어 매우 좋은 경험이었다! Step2 https://github.com/next-step/kotlin-lotto/pull/759 검증부는 하드 코딩을 사용하자 테스트코드에서 검증을 위해 도메인의 상수를 그대로 사용해 검증 로직을 짰는데 테스트에서는 상수를 직접 활용하기 보다는 하드 코딩을 해보는건 어떻겠냐는 피드백을 받았다. 검증부에 도메인 로직을 추가했을 때의 문제점은 다음과 같다. 무의미한 검증 사실상 프로덕션 코드를 복사 & 붙여넣기 한 것과 같다. 구현 코드와의 강결합 프로덕션 코드와 강결합하게 되면 결과는 동일하지만 로직이 변경되는 리팩..

도메인 프로퍼티 접근 제어자 custom setter와 getter의 사용 코틀린에서는 프로퍼티에 대한 getter와 setter를 자동으로 생성해주기 때문에 직접 getter를 구현하기보다는 아래 예시와 같이 코틀린을 좀 더 코틀린스럽게 구현할 수 있다. var stringRepresentation: String get() = this.toString() set(value) { setDataFromString(value) // parses the string and assigns values to other properties } 여기서 더 나아가, 도메인에 var 프로퍼티를 사용할 경우 외부에 변경 가능 지점이 노출되기 때문에 외부에 변경 가능 지점을 노출하고 싶지 않다면 private set 을 통..