출퇴근미니스터디

“‘사용자(User)’와 ‘권한(Role)’ 관계를 설계할 때, 단순히 enum으로 관리하는 것과 객체로 분리하는 것 사이에는 어떤 차이가 있을까?”enum은 단순한 권한 구분에는 적합하지만,사용자마다 다른 메뉴 접근 권한 같은 커스터마이징이 필요한 상황에서는 한계가

알림(Notification)이라는 도메인을 설계할 때,단순히 메서드 하나로 퉁치기보다는 다음과 같은 철학적 고민이 필요했다.“알림의 본질은 무엇인가?단순히 알리는 것일까, 아니면 더 복합적인 흐름을 가진 도메인인가?”이번 설계에서는 알림 시스템을 구성할 때,Notif

Notification 시스템을 전처리 → 전송 → 후처리 3단계로 구조화각 단계 내부는 복수의 Worker 처리 단위로 조립 가능하게 설계재사용성, 유연성, 타입 안정성을 모두 만족시키는 구조를 고민Noticefication: 전체 프로세스의 실행자 (Orchestr

✅ 설계 방향 요약 Noticefication은 실행 책임만 담당 (action(factory)) NotiHandlerFactory는 Pre / Transmit / Post 핸들러 조립 책임 각 NotiHandler는 내부에 파이프 구조 (NotiWorkPipe) 주

전략 패턴 + 파이프 구조를 활용한 알림(Notification) 처리 구조 설계Enum을 전략 선택 가이드로 활용하는 구조 설계PipeProvider로 핸들러별 파이프 조합을 분리실제 구현 흐름을 따라가며 타입 문제, 패키지 분리, 책임 분리를 실습App: 실행 진입

찐막.. 찐찐막 1. 오늘의 핵심 변화 요약 | 항목 | 변화 내용 | |------|-----------| | 메시지 책임 분리 | Message 생성 책임을 외부로 완전 위임 | | Notification 도메인 정리 | 단순히 send(Message)를 수행하고 결과만 반환 | | SendResult 구조 도입 | 전송 결과를 외부에서 판단 가...

A. 도메인 객체다.EmailMessage, SmsMessage 등 메시지 형태가 채널별로 다름유효성 검사, 생성 로직 등 도메인 로직 포함 가능단순 DTO가 아닌 의미를 가진 객체A. 생성자 내부.생성 시점부터 유효한 상태 보장테스트와 유지보수 쉬움팩토리나 외부에서

NotificationSender<T> 인터페이스 리팩토링EmailNotificationSender 구현체 예외 처리 흐름 정비T extends Message → 타입 안정성 확보throws NotificationSendException → 예외 흐름 명시됨Jav

A. 나는 GPT가 짠 코드를 검토하고, 확장 방향을 제시하는 역할을 한다.A.1\. 기본 기능이 작동하는지 확인2\. 로직 흐름이 올바른지 확인3\. 객체지향적 설계인지 점검4\. 실무 환경에 맞게 조정 요청A. 매우 공감. 직접 구현 감각이 무뎌지는 건 사실.→ 하

라는 단순한 개념으로 생각하고 있었으나. 그 밑에 한줄 더 있던 것을 기억해내야한다.단순하게 하나의 클래스는 하나의 책임을 진다고 생각하였을떄,책임이란 무엇인지에 대해 잘못 고민하게되면 "기능" 으로 오해하기 쉽다는 것을 알게됨그런식이라면 한클래스에 한줄이나 있겠다 야

보안 감각을 반영한 실전형 설계객체지향 감각 + 실무 현실성 모두 고려사용자가 이메일 입력발송 실패 여부 즉시 안내발송 성공 시 재설정 링크 전송실패 시 추가 인증 수단 제공비밀번호 재설정 성공 시 완료 안내"비밀번호 찾기는 고객 편의 기능이 아니라,사용자 데이터 보호

장바구니 기능을 객체지향적으로 설계실무 기준으로 재고 관리, 락 처리까지 고려기능 흐름뿐 아니라 시스템 안전성/사용자 경험까지 설계사용자가 상품을 선택한다.장바구니에 상품을 담는다.장바구니에 이미 있으면 수량 증가.수량 증가 시 재고 초과 여부 확인.품절 상품은 담기

"객체에게 묻지 말고, 시켜라."객체의 내부 상태를 꺼내서 조작하지 말고 객체에게 명령하고, 그 객체가 내부적으로 판단하고 처리하도록 만들 것int value = obj.increase(); → 실용적이지만 SRP 위반 우려 boolean changed = obj.

Post, User, Recommendation 도메인 설계추천 등록/취소 흐름 정리 (POST / DELETE)RESTful 설계 방식 복습userId는 세션/인증정보, postId는 URL 경로로 전달응답은 success/fail + 메시지 포함 방향 제안이미 알고

✅ 1. 실무에서 자주 쓰이는 표현 | 패턴 | 의미/용도 | 예시 | |:-----|:---------|:-----| | is~ | 상태 체크 | isValid, isEmpty, isAdmin | | has~ | 속성 보유 여부 | hasPermission, has

주문(Order) 상태 관리 시스템 설계도메인 모델링 + 상태 전이(State Transition) 설계 훈련읽히는 코드상태 전이 설계작은 if vs 큰 리팩토링Enum 기반 관리 vs 테이블 기반 전이 관리실용적 완벽주의 (데드라인 내 프로토타입 완성)완성 없는 완벽

선택: Role 객체로 분리이유: User는 역할만 가지며, 권한의 실체는 Role이 관리해야 책임 분리와 확장 용이선택: Permission 객체로 분리이유: 메뉴별, 행동별, 팝업 노출 등 다양한 권한 정의를 위해선 구조화 필요응답: 접근 가능한 메뉴, 메뉴별 허용

시스템 예외와 도메인 예외를 구분하고,응답 구조, 로그 처리, 책임 분리를 명확히 정의하는 설계 감각을 키운다.선택지 A. 하나의 예외 계층에서 처리한다 B. 비즈니스 예외와 시스템 예외를 분리해서 처리한다선택: B이유: 시스템 예외는 재시도/점검이 필요하고 도

테스트는 결과 검증이 아니라 설계 명세실패를 먼저 정의하고, 그것을 통과시키기 위한 구조만 도입도메인이 아니라 행위 중심으로 출발테스트는 하나의 사용자 시나리오구조는 테스트가 요구할 때만 등장한다PostRepository 도입 → 게시물 존재 검증CommentRepos

테스트 코드 없이 리팩토링하는 것은 비싼 비용을 감당해야 하는 무모한 행위이다.A. 여러 조건이 동시에 실패하도록 설계된 경우→ 어떤 조건이 실패했는지 테스트만 보고 알 수 없음A. 두 번 일하게 된다→ 테스트 통과 전에 구조 건드리면, 실패의 원인을 구분 못하고 혼란

하나의 기능이 아닌, 여러 도메인 간 연결을 다루기 시작게시물 → 댓글 → 신고 흐름을 행위 책임 기반으로 설계TDD 관점에서 각각의 도메인에 대해 테스트 단위를 어떻게 나눌지 설계테스트도 설계 대상이며, 중복 제거와 의미 명시가 중요게시물 삭제 시 댓글도 삭제되는지

퇴근 후 피로감이 커 공부는 어려운 상태였음.대신 GPT와 개발 이야기를 나누며 휴식의 일부로 삼음.액션 기반 설계에서 DbBaseAction이라는 중간 추상 클래스 도입 여부를 고민했음.플로우(TaskFlow)가 커넥션 생성, 전달, 종료까지 모든 책임을 지고 있었고

최근 액션 단위로 작업을 구성하는 워크플로우 구조를 다루는 프로젝트를 경험하면서다음과 같은 고민이 생겼다.실행 흐름 관리, 자원 처리, 상태 전달 등 여러 책임이 하나의 클래스에 몰려 있었다.결과적으로 단일 책임 원칙(SRP)이 무너지고, 테스트와 유지보수 모두 어려워