Backend/Architecture

Spring 기반 백엔드 개발을 하다 보면 MyBatis처럼 쿼리 중심의 DAO 패턴과, JPA + DDD 기반의 도메인 중심 개발을 주로 사용할 텐데 두 방식은 철학 자체가 다르다.따라서 비즈니스 로직을 어디에 둘지도 각각 다르다.이번 글에서는 두 방식의 차이점과, 그에 따라 비즈니스 로직을 어디에 배치하는 것이 좋은지를 알아보려 한다.🧩MyBatis에서의 구조와 로직 위치MyBatis는 Entity 객체가 Dumb Object(데이터 컨테이너)로 사용된다. 즉, 도메인 자체는 로직을 갖지 않으며, 모든 비즈니스 흐름은 보통 Service Layer에 위치한다.Controller → Service → DAO(Mapper) → SQL(XML)Controller: 요청/응답 처리Service: 비즈..

Java 개발을 하다 보면 `setXXX()` 메서드를 호출해 객체의 상태를 변경해야 하는 상황을 자주 마주하게 된다. 객체지향 설계 관련 글들을 보면 보통 Service Layer에서 setter를 호출해야 한다는 원칙이 어렴풋이 기억나는데, 막상 실제 프로젝트를 보면 setter 호출 위치가 Controller, Service 등 곳곳에 뒤섞여있어 참고하기 쉽지 않았다. 그래서 이번 글에서는 이 setter 호출에 대해 객체지향 설계의 원칙과 현실적인 상황을 함께 고려해 정리해보려고 한다.🧩setter 호출은 어디서 해야 할까?객체의 상태 변경(setter 호출)은 비즈니스 로직이 집중되는 Service Layer에서 처리하는 것이 가장 자연스럽다. 예를 들어,클라이언트로부터 받은 요청값(R..

백엔드를 공부하거나 프로젝트를 하다 보면 “비즈니스 로직은 어디에 둬야 한다”, “Controller에 비즈니스 로직을 넣지 마라” 같은 말을 자주 듣게 된다.하지만 막상 들으면 비즈니스 로직이 정확히 무엇을 의미하는지, 도메인과 도메인 모델이 같은 개념인지, 그리고 Controller, Service, Domain 중 어디에 두는 것이 맞는지 헷갈리기 쉽다. 이번 글에서는 비즈니스 로직의 정의부터 도메인과 도메인 모델의 차이, 그리고 비즈니스 로직의 올바른 위치까지 차근차근 살펴보려 한다.비즈니스 로직이란?비즈니스 로직(Business Logic)은 “시스템이 해결하려는 비즈니스 문제를 처리하는 핵심 규칙과 절차”를 의미한다.즉, 이 서비스가 어떤 규칙으로 동작해야 하는지를 결정하는 로직을 말한다. ..

서비스 계층에 비즈니스 로직이 너무 많아지고 가독성이 떨어지는 문제가 있었다.공통 로직이 있지만, 타입별로 유효성 검증 로직(Validator)과 핸들링 로직(Handler)이 달랐다. 처음엔 Validator + Handler를 모두 분리할까 고민했지만, 너무 잘게 쪼개면 관리가 오히려 복잡해질 수 있어서 Validator만 분리하기로 했다.그런데 여기서 또 공통 로직 + 타입별 로직을 깔끔하게 나누고 싶다는 고민이 생겼고, 전략 패턴과 팩토리 패턴을 적용해보기로 했다. 그래서 이번 글에서는 전략 패턴과 팩토리 패턴이 무엇인지, 그리고 둘을 어떻게 조합할 수 있는지 정리하려 한다.전략 패턴(Strategy Pattern)이란?전략 패턴은"같은 목적을 가진 여러 알고리즘(행동)을 정의하고, 필요할 때 교..

개발을 하다 보면, 공통 로직은 묶고 상황에 따라 다르게 동작하는 구조가 필요해진다.이때 자주 마주하게 되는 선택지가 바로 추상 클래스와 인터페이스다. 두 개념은 겉보기엔 비슷하지만, 설계 목적과 쓰임은 분명히 다르다.따라서 이번 글에서는 그 차이와 선택 기준을 실무 관점에서 정리해보려 한다.🧩추상 클래스와 인터페이스항목추상 클래스 (abstract class)인터페이스 (interface)상속단일 상속만 가능다중 구현 가능구현 여부일부 메서드 구현 가능기본적으로 구현 불가 (default는 예외)필드 사용인스턴스 필드 가짐 가능상수만 정의 가능주 용도공통 기능 제공 및 재사용구조 강제 및 다형성 구현주요 특징상태 + 동작 전달 가능오직 동작 계약만 전달⚙️상황별 선택 기준과 예시Validator / ..

API를 설계하다 보면 하나의 기능에도 다양한 요청 구조가 존재할 수 있다.예를 들어 단일 항목 등록, 다중 항목 일괄 등록, 간단한 등록, 복잡한 등록처럼 요청 방식이나 포함 필드가 달라지는 경우, 이를 어떻게 DTO 클래스로 잘 표현할 수 있을지 고민하게 된다. 따라서 이번 포스팅에서는 요청 JSON 구조에 따라 DTO를 어떻게 나누고 상속할 것인지, 그 판단 기준과 설계 전략을 정리해보려 한다.✅ 흔히 마주치는 JSON 구조예시로, 상품 등록 API를 설계한다고 가정했을때,클라이언트에서 보낼 수 있는 요청은 다음과 같이 다양할 수 있습니다.1. 단건 상품 등록 { "productId": "P1234", "name": "Notebook", "price": 120000}2. 다건 상품 등록 (일괄..

요청/응답을 처리하는 DTO와 DB 매핑 또는 도메인 로직을 담당하는 VO를 각각 만들면서, DTO에 적용한 것처럼 VO에도 Lombok의 @Getter, @Setter, @Builder 등을 자연스럽게 사용했다. 그런데 리뷰 도중 “VO에는 Lombok을 쓰면 안 좋아요”라는 피드백을 들었다.처음엔 의아했지만, 그 이유를 하나씩 살펴보니 VO에는 Lombok 사용을 지양해야 하는 명확한 근거들이 있었다. 따라서 이번 포스팅에서는 VO에 Lombok을 쓰면 안 되는 이유를 중심으로 정리해보려 한다.🔧 Lombok이란?Lombok은 Java 코드에서 반복적으로 작성되는 getter/setter, constructor, equals/hashCode 등의 코드를 애노테이션 기반으로 자동 생성해주는 라이브러..

API를 개발하던 중, 요청으로 들어오는 JSON 구조와 실제 DB에 저장해야 하는 컬럼 구조가 서로 다른 경우를 마주했다. 그동안은 상황에 따라 Model 클래스를 임의로 만들거나, DB 구조 또는 요청 구조 중 하나에 맞춰 사용하는 방식으로 처리해왔다. 하지만 이번에는 요청 객체를 그대로 DB에 저장할 수 없는 상황이 생기면서, 구조 분리를 어떻게 해야 할지 고민이 깊어졌다.이 과정에서 DTO와 VO의 개념을 다시 떠올렸지만, 정확히 언제 어떻게 나눠서 써야 하는지에 대해서는 명확하지 않았다. 따라서 이번 포스팅에서는 DTO와 VO의 정의, 구조, 사용 위치 등에 대해 정리해보려 한다.DTO와 VO란?🧾 DTO (Data Transfer Object)정의: 계층 간 또는 네트워크 전송 시 데이터를 ..

새로운 프로젝트에 합류하게 되면서 설계 단계부터 참여할 기회를 얻게 되었다. 그동안은 주로 웹 기반의 MVC 패턴에 익숙했지만, 이번에는 RESTful API 중심의 프로젝트를 진행하게 되어 프로젝트 구조를 어떻게 설계할 것인지에 대한 고민이 생겼다. 설계 원칙에 따라 다양한 구조가 존재하지만, 이번 프로젝트에는 도메인 중심 구조(Domain-Oriented Structure) 가 더 적합하다고 판단했다.이에 따라 이번 포스팅에서는 도메인 구조가 무엇인지, 내가 익숙했던 레이어 구조(Layered Architecture) 와는 어떤 차이가 있는지, 그리고 각각의 장단점과 선택 기준에 대해 정리해보려 한다.🧱 레이어 기반 구조 (Layered Architecture)레이어 기반 구조는 전통적인 아키텍처 ..