코딩딩/Spring

도메인 주도 설계(DDD)를 채택한 프로젝트에서 엔티티의 생성 시점(createdAt)과 수정 시점(updatedAt)을 자동으로 관리하려면 어떤 방식이 더 적합할까? 특히, 도메인 계층과 데이터 계층이 분리되어 있고, merge를 통해 업데이트가 이루어질 가능성이 높다면 설계 선택에 신중해야 한다. 이번 글에서는 @PreUpdate와 @UpdateTimestamp를 비교하며, DDD 방식에 적합한 구현 방법을 제안해보겠다. 1. DDD 관점에서의 엔티티 상태 관리 DDD에서는 도메인 계층이 핵심이다. 따라서 엔티티의 상태(createdAt, updatedAt) 관리는 애그리거트 루트에서 책임지거나, 이를 데이터 계층에서 투명하게 처리할 수 있어야 한다. 이러한 요구사항을 충족하기 위해: • 도메인 계층..

@Builder 어노테이션은 내가 가장 애용하는 도구 중 하나다. 객체 생성 시 높은 유연성을 제공하며, Spring을 사용할 때 자주 활용했다. 하지만 이러한 의존성이 때로는 과도했음을 돌아보게 되었다.@Builder의 유연성@Builder의 가장 큰 장점은 객체 생성의 유연함이다. 모든 매개변수를 한꺼번에 전달할 필요 없이, 가독성 있고 깔끔하게 객체를 생성할 수 있다. 이는 특히 복잡한 객체나 선택적 필드를 가진 객체를 생성할 때 매우 유용하다. 하지만 강력한 도구일수록 신중하게 사용해야 한다.Entity 클래스에서 @Builder의 문제점특히 DDD(Domain-Driven Design) 관점에서, 엔티티는 무결성과 캡슐화를 엄격히 준수해야 한다. @Builder가 제공하는 유연성은 이러한 원칙을..

소프트웨어 개발에서 "의존성"은 피할 수 없는 개념이다. 의존성을 적절히 관리하지 않으면 코드가 복잡해지고, 유지보수와 테스트가 어려워진다. 이번 포스팅에서는 의존성, 의존성 주입(DI), 의존성 역전(DIP) 개념과 이들이 테스트 가능성과 어떤 연관이 있는지 정리해보려고 한다.의존성이란?컴퓨터공학에서 말하는 의존성은 결합과 같은 개념으로, 한 객체가 다른 객체의 동작이나 데이터를 필요로 하는 관계를 의미한다.A가 B를 사용하면 A는 B에 의존한다.예: A 객체가 B 객체의 메서드를 호출하거나 데이터를 참조하면, A는 B에 의존성을 가진다.의존성은 소프트웨어에서 자연스럽게 발생하지만, 이 의존성이 과도하거나 명확히 드러나지 않으면 설계와 유지보수에 문제가 생길 수 있다.의존성 주입(DI, Dependen..

소프트웨어 개발에서 테스트는 단순한 "코드 검증" 이상의 역할을 한다. 특히, TDD(Test-Driven Development)와 BDD(Behaviour-Driven Development)는 테스트를 통해 설계와 개발 방향성을 잡아가는 접근법이다. 이번 포스팅에서는 TDD와 BDD를 중심으로, 테스트와 관련된 다양한 개념들을 정리해보려고 한다.SUT란?테스트하려는 대상을 SUT(System Under Test)라고 부른다.즉, 테스트의 주요 대상이 되는 시스템, 메서드, 혹은 클래스를 지칭하는 용어다.SUT를 잘 정의하는 것은 테스트의 초점을 명확히 하는 데 중요하다.BDD (Behaviour-Driven Development)BDD란?BDD는 TDD에 "행동(Behaviour)"을 강조한 방식이다...

TDD를 하면서 많은 사람들이 빠지는 함정이 있다. 바로 "테스트 커버리지에 집착하는 것"이다. 테스트는 어디까지, 어떻게 작성해야 할까? 그리고 모든 메서드를 테스트해야 할까? 이런 질문에 답을 찾기 위해 이번 포스팅에서는 TDD의 핵심과 테스트 코드 작성의 방향성을 정리해보려고 한다.너무나 명확한 코드는 테스트하지 말자모든 코드를 테스트하려는 강박은 때로는 비효율적이다. 특히, 너무 단순하거나 명확한 코드라면 테스트를 작성하지 않아도 될 수 있다. 예를 들어, 단순한 getter/setter, 혹은 너무 기본적인 로직은 테스트 작성 없이도 충분히 신뢰할 수 있다.테스트 작성에서 피해야 할 것무의미한 테스트단순히 "테스트 코드 커버리지를 높이겠다"는 목적만으로 작성된 테스트는 아무런 가치를 주지 못한다..

이번 포스팅에서는 Mockito를 활용해 Mock 객체를 만들고, 원하는 동작을 지정(Stubbing)하고, 메서드 호출 여부나 호출 순서를 검증하는 방법에 대해 정리해보려고 한다. 예제 코드는 JUnit5와 Mockito를 사용하고 있으며, @ExtendWith(MockitoExtension.class)를 통해 Mockito 관련 설정을 편리하게 적용했다.Mockito 기본 개념Mock 객체란?실제 객체처럼 동작하지만, 프로그래머가 원하는 대로 그 객체의 행위를 설정(Stubbing)할 수 있는 가짜 객체다. Mockito를 사용하면 아주 간단히 Mock 객체를 만들고 관리할 수 있다. Mock 객체를 통해 외부 의존성을 가진 코드(예: DB 접근, 외부 API 호출)를 테스트 시점에 격리시키고, 원하..

자바 개발자라면 단위 테스트를 작성할 때 가장 먼저 손이 가는 게 바로 JUnit다. JUnit5는 JUnit4에 비해 많은 변화가 있었고, 특히 스프링 부트 2.2버전부터는 스프링 부트 스타터를 통해 별다른 의존성 설정 없이 바로 JUnit5를 쓸 수 있게 해줬다. (물론 스프링 부트를 안 써도 JUnit 의존성만 추가하면 바로 가능하다.)Junit5를 쓰면서 굳이 public 접근 제어자를 붙일 필요도 없다. 이는 테스트 메서드를 찾고 실행할 때 리플렉션(Reflection)을 활용하기 때문인데, 이 덕분에 접근제어자 관련 제약이 줄어든다.Reflection: 자바 프로그램이 실행 중에 클래스 구조나 메서드 정보를 파악하고, 접근이 불가능할 것 같은 private 멤버에도 접근할 수 있는 기술이다. ..

@Vaild 어노테이션으로 유효성 검사를 하기 위해 다음과 같은 HTML 코드를 작성했다. Incorrect data Incorrect data 그리고 해당 뷰를 렌더링 하기 위해 다음과 같은 컨트롤러를 작성했다. @GetMapping("/articles/post") public String showArticleForm(Model model) { return "contents/community/community-write"; } 하지만 렌터링이 되지 않는 에러가 발생했고, th:object 를 사용하려면 dto를 model에 담아줘야 한다는 사실을 알게됐다. @GetMapping("/articles/post") public String showArticleForm(Model model) { model.a..

부트캠프에서 파이널 프로젝트를 진행하며 Entity를 생성하다가 문뜩 이런 생각이 들었다. Entity의 Id값은 null이 허용되지 않는데 어째서 Wrapper class인 Long타입으로 작성할까? 기존에는 단순히 하이버네이트에서 권장하는 스펙이 Wrapper class라서 생각없이 작성했지만 저번 멘토님이 지적해주신 사항이 떠올라 찾아보기로 했다. 1. 표현 범위 만약 실제로 배포가 완료된 서비스에서 int형을 사용한다면 저장 범위를 뛰어넘는 수가 Id값에 할당될 수 있다. 2. Null 처리 원시타입 long에 null이 들어온다면 0으로 값이 처리된다. 하지만 entity의 관점에서 봤을땐 0은 null이 아닌 값으로 본다. id가 없을때 null을 선언함으로 id가 없다는 것을 보장할 수 있게..

JPA를 사용하며 OneToMany 관계를 DTO로 변경하는 과정에서 N+1 문제가 심심치 않게 발생하는 것을 발견할 수 있다. 기존엔 방법을 몰라 모든 연관관계를 fetch join으로 처리하면 되겠다고 생각했지만 해당 방법은 페이징 처리가 불가능하다는 단점이 있다는 사실을 알게되었다. 그렇다면 해결 방법으로는 어떤것들이 있을까? 실습에 사용될 Entity OrderEntity @Entity @Getter @Setter @Table(name = "orders") // 이렇게 선언해주면 함부로 기본 생성자로 객체를 생성할 수 없다 @NoArgsConstructor(access = AccessLevel.PROTECTED) public class Order { @Id @GeneratedValue @Colum..