백엔드 개발자로 가는길

헥사고날 아키텍처 도입데이터베이스 변경 리펙토링 과정에서 두가지 문제점을 발견했습니다.DB 엔티티와 도메인 로직의 결합서비스 로직과 데이터베이스 강결합두 문제점을 통해 DDD와 Clean Architecture의 필요성을 느꼈습니다.이를 구현하기 위해 헥사고날 아키텍처를 도입하기로 결정했습니다.레이어드 아키텍처 → 헥사고날 아키텍처기존 패키지 구조- controller- service- entity- repository- dto  헥사고날 아키텍처 적용 범위헥사고날 아키텍처의 핵심은 포트와 어댑터를 통해 각 계층별 의존성을 줄여 변경이나 확장에 유리하도록 하는 것 입니다.따라서 아래와 같은 구조로 설계할 계획을 세웠습니다.패키지 구조- controller - controller.java - dto ..

문제 상황 친구 목록 동기화 과정에서, 이미 존재하는 친구 데이터를 업데이트하고 새 데이터는 추가로 저장해야 한다. 하지만 기존 친구 데이터가 업데이트되지 않고, 새로운 데이터로 중복 저장되는 문제가 발생. 원인 분석 JPA에서 엔티티를 업데이트하려면, 해당 엔티티가 영속성 컨텍스트에서 관리되어야 한다. 문제 지점: FriendEntity로 변환하는 과정에서 id가 누락되어, JPA는 이를 새로운 엔티티로 간주하고 저장. 결론: id 필드가 없는 경우, JPA는 해당 엔티티를 식별할 수 없어 영속성을 판단하지 못하고, 기존 데이터를 업데이트하지 못함. 문제 코드  동기화 로직 // 친구 목록 동기화 로직중 일부friendRepository .findByConsumerIdAndToConsume..

https://www.acmicpc.net/problem/1939골드3구현 방법1. 문제 조건N: 섬의 수 (2 ≤ N ≤ 10,000)M: 다리의 수 (1 ≤ M ≤ 100,000)C: 다리의 최대 중량 (1 ≤ C ≤ 1,000,000,000)두 섬 사이의 여러 경로 중, 한 번의 이동에서 옮길 수 있는 물품들의 최대 중량을 구해야 한다.다리마다 중량 제한이 존재하며, 이를 초과하면 경로로 사용할 수 없다.2. 완전탐색의 비효율성만약 BFS를 통해 모든 가능한 경로를 탐색하는 방식으로 접근하면:시간 복잡도는 최악의 경우 O(2^M)에 도달할 수 있다.이유: 각 다리를 선택하거나 선택하지 않는 경우의 수를 모두 고려해야 하기 때문이는 M=100,000일 경우 비현실적으로 많은 계산을 요구하기 때문에 적..

이번에 데이터베이스를 변경하면서 DDD와 Clean Architecture의 필요성을 느꼈습니다. 참고: 데이터베이스를 변경한 이유는 아래 포스팅에 있습니다. https://kdozlo.tistory.com/74  친구 정보, Redis에서 MySQL로 옮긴 이유상황현재 사용자의 친구 정보들을 "카카오톡 친구 API"를 통해 받은 뒤, redis에 저장해 놓고 있었다.하지만 "자신의 친구들 중 친한 친구를 표시할 수 있다."라는 기능을 제공하고 있고, 이 정보 또kdozlo.tistory.com 기존 방식의 문제점 1. DB 엔티티와 도메인 로직의 결합 기존 방식에서는 DB 엔티티(Friend)에 도메인 로직(예: toggleFavorite)을 포함하여 구현했습니다. 이로 인해 데이터베이스와 도메인 로직..

친구 정보, Redis에서 MySQL로 옮긴 이유상황현재 사용자의 친구 정보들을 "카카오톡 친구 API"를 통해 받은 뒤, redis에 저장해 놓고 있었다.하지만 "자신의 친구들 중 친한 친구를 표시할 수 있다."라는 기능을 제공하고 있고, 이 정보 또한 redis에 함께 저장하고 있다.문제점1. 인메모리 구조인 redis에서 정보가 사라질 경우, 친구 목록은 "카카오톡 친구 API"를 통해 다시 받으면 되지만, 친한 친구 정보는 복구할 수 있는 방법이 쉽지 않다. 또한 우리 서비스에서 제공하는 기능에 대한 정보를 인메모리 구조인 레디스에서 관리하는 것이 자연스럽지 않다고 판단했다. 2. 친구들의 펀딩 게시글 조회 기능을 구현 할 때 redis를 통해 친구 목록을 받은 후, 이 정보를 바탕으로 mySQL..