왜 처음엔 TypeORM을 그대로 사용했을까?처음 chat-service를 설계할 때는 익숙한 방식대로 TypeORM의 @Entity를 활용해 곧바로 테이블 구조를 정의하고, 그 위에서 도메인 로직을 작성했습니다. 아래는 그 당시 사용하던 ChatRoom 엔티티의 일부입니다.@Entity()export class ChatRoom { @PrimaryGeneratedColumn() id: number; @Column() type: 'PUBLIC' | 'PRIVATE'; @Column({ nullable: true }) itemId: number; @Column() createdBy: number; @Column({ default: true }) isActive: boolean; @Crea..

도입 배경: Controller에 쌓여가는 new 연쇄처음 인증 서비스를 개발할 때는 다음과 같은 방식으로 객체를 조립하고 있었습니다.const userRepository = new UserRepository(...);const sessionRepository = new SessionRepository(...);const tokenIssuer = new JwtTokenIssuer();const tokenService = new TokenService(tokenIssuer, ...);const registerUsecase = new RegisterUserUsecase(userRepository, sessionRepository, ..., tokenService);const registerController..

Spring 실무에서 자주 쓰이는 디자인 패턴 4가지– 객체 설계와 책임 분리를 고민한다면 꼭 이해해야 할 구조들서비스를 설계하다 보면 비슷한 문제가 반복된다.예를 들어 객체를 생성하는 로직이 여기저기 중복되거나, 조건문이 늘어나면서 정책을 분리하고 싶은 욕구가 생긴다.이런 상황에서 코드의 구조를 개선하고자 할 때 가장 강력한 도구 중 하나가 디자인 패턴이다.이번 글에서는 Spring 기반의 실무 개발에서 자주 사용되고, 실제로 효과를 본 4가지 패턴을 정리했다.FactoryBuilderStrategyObserver각각의 패턴은 단지 “이렇게 써야 한다”는 가이드가 아니라, “왜 이런 구조가 필요한가”에 대한 고민에서 출발한다.1. Factory Pattern – 객체 생성 책임을 분리하자왜 필요한가?서..

최근 프로젝트에서 Spring을 활용해 Item 등록 기능을 Clean Architecture 방식으로 설계해보았습니다. 이 구조가 왜 효과적인지, 어떤 방식으로 구성되었는지를 직접 정리해봅니다. 1. 전체 구조의 목적Controller → DTO → UseCase(Command) → Domain(Entity) + Factory → Repository → DBSpring에서는 역할 분리를 명확히 하여 테스트 용이성과 유지보수성을 높이는 것이 핵심입니다.각 계층은 다음과 같은 목적을 가집니다:Controller: HTTP 요청/응답 처리DTO: 외부 입력을 안전하게 감싸는 구조Command: 내부 유스케이스 전용 입력 모델UseCase: 실제 기능 로직의 진입점Entity: DB와 매핑되는 도메인 객체Fa..

SOLID란?SOLID 원칙은 객체 지향 설계에서 유지보수성과 확장성을 높이기 위한 다섯 가지 핵심 원칙이다. Robert C. Martin(일명 Uncle Bob)이 정리한 이 원칙들은 실제로도 많은 OOP 기반 시스템에서 코드 품질과 구조 개선에 기여한다.내가 직접 설계하고 리팩토링한 인증 서비스(auth-service)와 결제 서비스(escrow-service)에도 이 원칙들을 적용하며 실무적 감각을 쌓았다. S - 단일 책임 원칙 (Single Responsibility Principle, SRP)정의: 하나의 클래스는 하나의 책임만 가져야 한다.효과: 변경의 이유가 하나뿐이므로 코드 수정 시 다른 기능에 영향을 주지 않음.예시 적용RegisterUserUsecase / LoginUserUseca..