불변 객체는 여러 가지 장점을 가지고 있습니다. 특히 Thread Safe하여 병렬 프로그래밍에서 유용하며, 동기화를 고려하지 않아도 안전하다는 사실은 널리 알려져 있습니다. 하지만 불변 객체에 대해 공부하면서 두 가지 의문이 들었습니다. 불변 객체가 가비지 컬렉션(GC)의 성능을 높일 수 있다는 점이 잘 이해되지 않았습니다. 일반적으로 불변 객체는 한 번 생성된 후 수정이 불가능하기 때문에 GC와 어떤 관계가 있을지 궁금했습니다.불변 객체의 상태를 변경할 때마다 새로운 객체를 생성해야 한다는 점에서, 성능 저하에 대한 우려가 있었습니다. 객체를 자주 생성하는 것이 과연 효율적인지에 대해 의문이 들었습니다.의문을 해결하기 위해서 먼저, 가비지 컬렉션의 대상이 뭔지 알아야합니다. 가비지 컬렉션의 대상 가비..

DDD Entity와 JPA Entity 구분의 고민 EATceed 프로젝트에서는 JPA의 Entity와 도메인 주도 설계(DDD)의 Entity를 구분하여 코드를 작성하고 있습니다. 하지만, 몇몇 JPA 엔티티와 DDD 엔티티들이 구조적으로 거의 흡사하여, 이 둘을 구분하는 것이 옳은 선택인지 고민이 생겼습니다.제가 생각하는 장점과 단점은 아래와 같습니다.장점명확한 책임 분리DDD Entity는 비즈니스 로직과 도메인 모델링에 집중하고, JPA Entity는 데이터베이스와의 매핑에만 집중하게 되어 각 클래스의 책임이 명확해집니다. 이를 통해 코드를 더 이해하기 쉽고 유지보수하기 용이하게 만듭니다.도메인 모델의 순수성 유지DDD Entity는 데이터베이스에 의존하지 않고, 순수한 도메인 로직만을 포함하게..

현재 상황앱을 출시하기 전 “앱 출시 6개월 후 활발하게 활동하는 회원이 100명 정도라 가정”하고 쿼리 테스트를 진행하였습니다. 초기 데이터 회원 100명이 6개월 동안 아침, 점심, 저녁, 간식을 모두 섭취한다고 가정하면, 총 72,000개의 식사가 이루어집니다. 이는 아래와 같이 계산할 수 있습니다100명 * 6개월 * 30일 * 4끼 = 72,000끼그러나, 유저가 회원가입한 시기를 고려하여 프로시저를 사용해 각 테이블에 데이터를 삽입한 결과, 실제 기록된 식사 횟수(MEAL_COUNT)는 67,400개로 나타났습니다.또한, 한 끼당 4가지 음식을 섭취한다고 가정하였습니다. 정확한 쿼리 테스트를 위해 쿼리 캐시 Off SHOW VARIABLES LIKE 'query_cache_type'; 아직 실..

https://rasony.tistory.com/190 헥사고날 아키텍처 회고EATceed 프로젝트에서 헥사고날 아키텍처를 사용해보며, 고민해본 점을 서술해보려고 합니다.먼저, 헥사고날 아키텍처를 도입한 이유입니다. 헥사고날 아키텍처를 도입한 이유 계층형 아키텍처rasony.tistory.com 프로젝트를 진행하며, 외부 서비스를 이용해야하는 기능들이 점점 더 생기기 시작하였습니다. 구체적으로, AWS의 S3와 SES 서비스를 이용하고, 데이터베이스로는 MariaDB와 Redis를 사용하게 되었습니다.또한, 특정한 트리거로 인한 스케줄링 기능을 사용하기 위해 Quatz를 도입하였습니다. 이에 아래와 같은 패키지가 추가되었습니다.  현재 패키지 구조는 도메인기반으로 패키지 구조를 나누고 있었습니다.하지만,..

배경프로젝트가 진행되면서 Jacoco를 도입해 테스트 커버리지를 측정하고, 처참한 커버리지를 보여줌으로써 팀원들(저 포함..)이 테스트를 작성하도록 독려했습니다. 이를 통해 테스트 코드의 수가 점차적으로 늘어나고 있었습니다.  또한, 테스트 컨테이너를 활용하여 테스트 환경을 구축하는 데 힘을 쏟았습니다. 어느덧, 테스트의 수가 70개가 넘어갈 때쯤 Run All Tests할 때 걸리는 시간이 꽤나 늘어나 있었습니다. ApplicationContext Caching 스프링에서는 테스트에 사용되는 애플리케이션 컨텍스트를 생성하고 관리하여 테스트에 적용해주는 테스트 프레임워크를 제공합니다. 테스트 컨텍스트 프레임워크는 테스트가 사용하는 컨텍스트를 캐싱해서 여러 테스트가 컨텍스트를 공유하는 방법을 제공합니다.하..

프로젝트를 진행하며 아래의 도메인 클래스가 너무 많은 기능을 가지고 있어 리팩토링할 필요가 있다고 생각했습니다.public class Nutritionist { private DailyMeal dailyMeal; private Member member; public boolean evaluateProteinAchieve() { return member.measureTargetProtein() - getCurrentProtein() 위의 Nutritionist 즉 영양사 도메인은 단백질, 탄수화물, 지방, 칼로리 달성률을 계산하는 책임과 영양사 도메인을 생성하는 책임을 가지고 있습니다.하나의 도메인이 너무 많은 책임을 가지고 있다고 생각하여 책임을 분리하기로 하였습니다. -  ..