과정을 즐기자

프로젝트를 진행하면서 UUID로 임의의 문자열을 생성하는 로직이 있었습니다.128비트의 32글자 UUID 버전 4를 사용했습니다.매초 10억개를 100년동안 만들더라도 단 하나의 중복이 발생할 확률이 약 50% 정도라고 알려져 있습니다. 따라서 따로 고려를 해본적은 없었지만 서비스가 정말 어마어마하게 커져 충돌 발생 가능성을 고려해야 한다면어떠한 식으로 대처를 해야할 지에 대해 작성해보겠습니다.📘 대략적인 규모 추정하기16바이트의 UUID를 매초 10억개씩 100년동안 만들었다고 가정해본다면 기가, 테라, 페타를 넘어약 50 엑사바이트 정도의 데이터입니다. 이는 하나의 데이터베이스에서 저장하기에는 너무나도 큰 수치입니다.우선은 하나의 데이터베이스에 저장하는 경우를 생각해보고 추가적으로 스케일 아웃했을 ..

이번 글에서는 if, else if 가 점점 많아져 가독성이 좋지 않은 코드를 개선해보는 작업을 해보겠습니다.먼저 요구 사항부터 살펴보겠습니다. 1. 간단한 결제 로직을 구현한다.2. 현재 네이버 페이, 카카오 페이, 토스 페이, 애플 페이를 지원한다. 인터페이스를 활용하여 결제 로직을 구현해보겠습니다.📕 PaymentProviderPaymentProvider는 페이 종류를 나열하였습니다.📕 PaymentChannelPaymentChannel 인터페이스는 해당 페이의 종류인지 확인하는 isSupport() 메소드와 결제를 처리하는 processPayment()메소드가 있습니다. PaymentChannel 인터페이스의 구현체로 NaverPayChannel, KakaoPayChannel, TossPayC..

이번 글에서는 프로젝트를 진행하면서 복잡한 비즈니스 로직을 풀어냈던 방법에 대해 작성해보려고 합니다.⛳️ 요구 사항먼저 요구사항에 대해 정리해보겠습니다. 1. 각각의 회원이 각자의 캘린더를 가지고 있음2. 회원은 여러 모임에 참여할 수 있음3. 모임장은 참여한 회원들의 캘린더 정보를 바탕으로 팀원들의 가용시간을 확인할 수 있음4. 이 가용시간을 바탕으로 특정 시간에 미팅을 생성할 수 있음 위와 같은 요구 사항이 있습니다. 이번 글에서는 3번에 대한 요구 사항을 중점적으로 이야기를 해볼텐데 대략 아래와 같은 UI를제공합니다. 각 회원의 캘린더 정보를 가져와서 하나의 캘린더에 색상으로 표현을 합니다.색상이 진할 수록 가능한 사람이 많은 시간대를 의미하며 해당 캘린더를 클릭하면 가능한 회원의 정보를 볼 수 있..

그동안 도메인과 엔티티를 분리하는 것에 대한 장점이 크게 납득이 되지 않았습니다.하지만 개인 프로젝트에서 여러 가지 테스트를 하며 고민해보고 인턴을 하며 회사 코드에 적용을 해보았는데이것이 꽤 유의미한 작업이 될 것이라고 생각했습니다. 요구사항에 대한 구현을 더 잘하기 위해 도메인과 DB 엔티티를 분리하는 작업을 해보겠습니다.📕 엔티티와 Dto를 분리 먼저 엔티티와 Dto 분리에 대해 이야기 해보겠습니다. 그동안 엔티티와 Dto를 분리하는 작업은 많이 해왔습니다. 요청과 응답에서 엔티티를 직접 사용하면 안되는 이유이번 글에서는 요청과 응답에서 엔티티를 직접 사용하면 안되는 이유에 대해서 작성해보려고 합니다. 일단.. 너무 기계적으로 dto를 사용했기 때문에 왜 dto가 필요한지를 생각해보려고 합니다. ..

Spring 프레임워크를 이용해 개발하다보면 여러 장점이 있습니다. DI/IoC 컨테이너, 테스트 용이, 그리고 스프링부트를 사용한다면 내장 톰캣, 버전 설정, 자동 구성.. 등 여러 장점이 있습니다. Spring은 객체지향 프로그래밍을 더 잘할 수 있도록 도와줍니다. 각각의 역할과 책임을 분리하도록 개발을 유도하기 때문입니다. 이때 가장 먼저 접하는 아키텍쳐는 Layerd Architecture로 크게 3가지로 나눈다면 클라이언트 요청을 받고 응답을 해주는 Presentation Layer, 비즈니스 로직을 처리하는 Application Layer, 데이터베이스에 접근하는 Data Access Layer로 나눌 수 있습니다. 저도 이러한 구조로 계속 개발을 해왔지만 기능이 많아지고 복잡해질 수록 문제점..