Day 1 DDD 강의에 앞서, 앞으로 고도화해 나갈 프로젝트의 도메인을 직접 분석해보는 사전 과제입니다. 이 과제의 목적은 정답을 맞히는 것이 아니라, 현재 코드가 어떤 방식으로 서로 얽혀 있는지 스스로 파악하고 체감해보는 것입니다. 강의 시간에는 이러한 얽힌 연관관계를 하나씩 분리해 나가며, 도메인 경계를 세우는 과정을 함께 살펴볼 예정입니다.
(중요) 아직 설계에 익숙하지 않으신 분은 해당 과제가 어려울 수 있습니다. 전혀 걱정하지 않으셔도 됩니다, 강의 때 같이 진행해보고 그래도 이해가 안 가신다면 강의 이후 개인적으로 봐드리겠습니다.
현재 프로젝트는 하나의 모놀리식 프로젝트에 아래 6개 도메인이 섞여 있습니다.
| 도메인 | 주요 Entity |
|---|---|
| 유저 (User) | User |
| 셀러 (Seller) | Seller |
| 상품 (Product) | Product |
| 장바구니 (Cart) | Cart, CartItem |
| 주문 (Order) | Order, OrderItem |
| 결제 (Payment) | Payment |
각 Entity는 다음 경로에 있습니다.
src/main/java/com/growmighty/lectures/firstday/tangledmonolith/
├── user/User.java
├── seller/Seller.java
├── product/Product.java
├── cart/Cart.java
├── cart/CartItem.java
├── order/Order.java
├── order/OrderItem.java
└── payment/Payment.java
현재 구현된 Entity 코드(특히 JPA 연관관계 어노테이션)를 직접 읽고, Entity 간의 연관관계를 draw.io 로 다이어그램으로 표현해주세요.
아래는 다른 도메인의 예시입니다. 우리 프로젝트와 모양은 다르지만, 이런 식으로 그려주시면 됩니다.
- 각 Entity를 네모 박스로 그리고, 한글명과 영문 클래스명을 함께 적기 (예:
주문 (Order)) - Entity 사이를 선으로 연결하고, 그 선 위에 연관관계 종류를 표기
@OneToOne,@OneToMany,@ManyToOne,@ManyToMany
- 방향(누가 누구를 참조하는지) 과 다중성(1, N) 을 화살표 / 까치발 표기로 드러내기
💡 예시 이미지처럼 "박스 + 연결선 + 연관관계 어노테이션 라벨" 형태면 충분합니다. 디자인보다 연관관계를 정확히 읽어내는 것이 중요합니다.
⚠️ 위 이미지는 참고용 예시이며, 우리 프로젝트의 실제 도메인과는 다릅니다. 실제 코드를 보고 직접 그려주세요.
코드를 읽을 때 아래를 단서로 삼으세요.
- 필드에 붙은
@OneToOne/@OneToMany/@ManyToOne어노테이션 @JoinColumn(name = "...")→ 외래키(FK)를 누가 들고 있는지mappedBy = "..."→ 양방향 관계인지, 연관관계의 주인이 누구인지cascade,orphanRemoval,fetch옵션 → 함께 묶여 움직이는 객체 묶음(힌트!)
- draw.io 다이어그램 파일(
.drawio) 또는 내보낸 이미지(.png/.jpg)
과제 1에서 그린 다이어그램을 보면서, "지금 이 코드, 이대로 괜찮을까?" 를 스스로 질문해보고 자유롭게 서술해주세요.
정답은 없습니다. 느낀 점, 불편한 점, 위험해 보이는 점을 솔직하게 적어주세요. 수업에서 다룰 내용을 미리 고민해보는 것이 목적입니다.
아래 질문은 생각을 돕기 위한 힌트일 뿐, 전부 답할 필요는 없습니다.
-
연관관계의 방향과 결합도
- 한 Entity가 다른 도메인의 Entity를 객체로 직접 참조하고 있나요?
- 예를 들어
OrderItem이Product를 직접 들고 있을 때, 어떤 문제가 생길 수 있을까요? - 한 도메인을 수정하면 다른 도메인까지 영향을 받게 되지는 않나요?
-
도메인 경계
- 지금 6개 도메인은 서로 명확히 구분되어 있나요, 아니면 거미줄처럼 얽혀 있나요?
- "이 객체는 어느 도메인의 것인가?"를 명확히 말할 수 있나요?
-
데이터 정합성 / 변경에 대한 취약성
OrderItem이Product를 참조하는데, 주문 이후 상품 가격이 바뀌면 어떻게 될까요?- 주문 당시의 정보는 어떻게 보존되어야 할까요?
-
객체로 직접 참조 vs ID로 간접 참조
- 지금처럼 객체로 직접 참조하는 방식의 장점과 단점은 무엇일까요?
- 만약 도메인을 나중에 별도 서비스로 분리한다면 어떤 문제가 생길까요?
-
(선택) 비즈니스 로직의 위치
- 도메인 규칙(재고 차감, 금액 계산 등)은 지금 어디에 작성되어 있나요?
- Entity는 단순히 데이터만 담는 그릇 역할만 하고 있지는 않나요?
-
(선택) 이외에 코드 수정이 필요하다고 느끼는 부분을 자유롭게 서술해주세요!
- 자유 형식 문서 (
.md,.txt,.docx,.pdf등 무엇이든 OK) - 분량 제한 없음 — 3~5개 문제점을 골라 각각 2~3줄씩만 적어도 충분합니다.
- 제출 기한: Day 1 수업 시작 전까지
- 제출물 2종 (폼에서 한 번에 제출)
- 도메인 연관관계 다이어그램 (draw.io 파일 또는 이미지) → 파일 업로드
- 코드 문제점 서술 → 폼에 직접 작성 (또는 문서 파일 업로드)
⚠️ 파일 업로드를 위해 구글 계정 로그인이 필요합니다.- 완벽하지 않아도 됩니다. 직접 코드를 읽고 고민한 흔적이 가장 중요합니다. 💪
이 과제에서 느낀 "얽힘"과 "불편함"을, 수업에서 하나씩 끊어내며 해결해 나갈 예정입니다. 가벼운 마음으로, 그러나 진지하게 코드를 들여다봐 주세요!