docs(10_Wiki): 위키 전체 재구성 — Topic_* 폴더를 4개 카테고리로 통합 + 대규모 중복 제거
Topic_Agent/Topic_Blog/Topics/Topics_Biz/Topics_Meeting/Topics_Rag의 마크다운 지식 문서를 Topic_General/Topic_Programming/Topic_Graphic/Topic_Business 4개 카테고리로 재분류. - 중복 제거: frontmatter의 status:duplicate/merged + duplicate_of/redirect_to 필드로 자기 자신을 중복으로 선언한 리다이렉트 stub 1032개 제거, 완전 동일 내용 파일 472개 제거, 동일 파일명·다른 내용 충돌 시 더 큰(완전한) 버전만 유지(162개 제거) — 총 1639개 중복 제거. - 분류: 폴더 단위로 명확한 항목(AI_and_ML/Coding/Architecture 등 → Programming, Comfyui/Visual_Effects → Graphic, Topics_Biz/Topics_Meeting/사업 등 → Business, Poetic_Blog_Writing/창의성/Game_Design 등 → General)은 폴더 우선순위로, 나머지 혼재 폴더(Topic_Agent/Topic_Blog/Topics 루트/Thinking & Reasoning/Other/UI_UX_Assets)는 title/tags 키워드 스코어링으로 파일 단위 분류(불명확한 경우 General로 폴백). 원본 폴더명은 "From_*" 서브폴더로 보존해 추적 가능성 유지. - 최종 배치: Programming 2784 / General 1608 / Graphic 285 / Business 249 = 4926개 문서. - 에이전트 운영 상태(.astra/.agent/.obsidian/sessions/memory/_company/docs/lessons/_shared/src)는 지식 콘텐츠가 아니므로 재분류 대상에서 제외하고 원위치 유지. - Topics/Topic_email(상위 보호 폴더 Topic_email과 파일명 100% 중복) 삭제 — 보호 폴더 자체는 미변경. - 완전히 비게 된 Topic_Agent/Topic_Blog/Topics_Biz/Topics_Rag 폴더 제거.
This commit is contained in:
Antigravity Agent
@@ -0,0 +1,204 @@
|
||||
---
|
||||
id: wiki-2026-0508-유스케이스-use-cases
|
||||
title: 유스케이스 (Use Cases)
|
||||
category: 10_Wiki/Topics
|
||||
status: verified
|
||||
canonical_id: self
|
||||
aliases: [Use Cases, 유스케이스, Use Case Analysis]
|
||||
duplicate_of: none
|
||||
source_trust_level: A
|
||||
confidence_score: 0.9
|
||||
verification_status: applied
|
||||
tags: [requirements, analysis, uml, agile, design]
|
||||
raw_sources: []
|
||||
last_reinforced: 2026-05-10
|
||||
github_commit: pending
|
||||
tech_stack:
|
||||
language: any
|
||||
framework: any
|
||||
---
|
||||
|
||||
# 유스케이스 (Use Cases)
|
||||
|
||||
## 매 한 줄
|
||||
> **"매 actor 가 매 system 의 의 의 의 achieve 의 의 의 goal 의 의 narrative"**. 매 Ivar Jacobson (1986) 가 의 의 OOSE 의 의 의 introduce 의 requirement engineering 의 의 의 핵심 의 의 의 artifact. 매 2026 — 매 Clean Architecture 의 의 application layer 의 의 의 first-class 의 building block.
|
||||
|
||||
## 매 핵심
|
||||
|
||||
### 매 구성 요소
|
||||
- **Actor** — 매 system 외부 entity (user, system, time).
|
||||
- **Goal** — 매 actor 의 의 achieve 의 want 의 outcome.
|
||||
- **Scenario** — 매 step-by-step 의 flow.
|
||||
- **Precondition / Postcondition** — 매 state 의 boundary.
|
||||
- **Extensions** — 매 alternate 의 exception flow.
|
||||
|
||||
### 매 Use case 의 levels (Cockburn)
|
||||
1. **Cloud** — 매 strategic 의 vague.
|
||||
2. **Kite** — 매 summary level.
|
||||
3. **Sea** — 매 user goal (most common).
|
||||
4. **Fish** — 매 sub-function.
|
||||
5. **Clam** — 매 too low / implementation detail.
|
||||
|
||||
### 매 vs User Story
|
||||
- Use case — 매 흐름 의 narrative 의 detailed.
|
||||
- User story — 매 한 줄 의 "As a X, I want Y, so that Z".
|
||||
- 매 Agile — 매 user story; 매 enterprise — 매 use case.
|
||||
|
||||
### 매 Use case 의 Clean Architecture 의 의 의 manifestation
|
||||
- 매 application layer 의 의 의 한 use case = 한 class.
|
||||
- 매 input port (request) + output port (response).
|
||||
- 매 framework / DB 의 의 의 independence.
|
||||
|
||||
## 💻 패턴
|
||||
|
||||
### 매 Use case template (Cockburn)
|
||||
```markdown
|
||||
# UC-007: Place Order
|
||||
|
||||
**Primary Actor**: Customer
|
||||
**Goal**: Submit order and receive confirmation
|
||||
**Precondition**: User authenticated, cart non-empty
|
||||
**Postcondition (success)**: Order persisted, payment authorized
|
||||
**Postcondition (failure)**: Cart unchanged
|
||||
|
||||
## Main Success Scenario
|
||||
1. Customer reviews cart
|
||||
2. Customer enters shipping address
|
||||
3. Customer selects payment method
|
||||
4. System calculates total (items + tax + shipping)
|
||||
5. Customer confirms
|
||||
6. System charges payment
|
||||
7. System creates order
|
||||
8. System sends confirmation email
|
||||
|
||||
## Extensions
|
||||
6a. Payment declined:
|
||||
6a1. System notifies customer
|
||||
6a2. Return to step 3
|
||||
7a. Inventory unavailable:
|
||||
7a1. System refunds payment
|
||||
7a2. System notifies customer
|
||||
```
|
||||
|
||||
### 매 Clean Architecture 의 의 의 use case (Java)
|
||||
```java
|
||||
public interface PlaceOrder {
|
||||
Result execute(Request req);
|
||||
|
||||
record Request(UUID userId, List<Item> items, Address ship) {}
|
||||
sealed interface Result {
|
||||
record Success(UUID orderId) implements Result {}
|
||||
record PaymentFailed(String reason) implements Result {}
|
||||
record OutOfStock(List<UUID> skus) implements Result {}
|
||||
}
|
||||
}
|
||||
|
||||
@Component
|
||||
class PlaceOrderInteractor implements PlaceOrder {
|
||||
private final OrderRepo orders;
|
||||
private final PaymentGateway pay;
|
||||
private final InventoryService inv;
|
||||
|
||||
@Override
|
||||
public Result execute(Request req) {
|
||||
var unavailable = inv.check(req.items());
|
||||
if (!unavailable.isEmpty()) return new OutOfStock(unavailable);
|
||||
|
||||
var charge = pay.charge(req.userId(), total(req));
|
||||
if (charge.failed()) return new PaymentFailed(charge.reason());
|
||||
|
||||
var order = Order.create(req);
|
||||
orders.save(order);
|
||||
return new Success(order.id());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 매 Use case diagram (PlantUML)
|
||||
```plantuml
|
||||
@startuml
|
||||
left to right direction
|
||||
actor Customer
|
||||
actor Admin
|
||||
rectangle Shop {
|
||||
Customer --> (Browse Catalog)
|
||||
Customer --> (Place Order)
|
||||
Customer --> (Track Shipment)
|
||||
(Place Order) ..> (Charge Payment) : <<include>>
|
||||
(Place Order) ..> (Apply Discount) : <<extend>>
|
||||
Admin --> (Manage Inventory)
|
||||
}
|
||||
@enduml
|
||||
```
|
||||
|
||||
### 매 User story 의 의 의 의 mapping
|
||||
```markdown
|
||||
# Story
|
||||
As a Customer
|
||||
I want to place an order
|
||||
So that I receive my purchase
|
||||
|
||||
## Acceptance Criteria (Gherkin)
|
||||
Given I have items in my cart
|
||||
When I confirm checkout with valid payment
|
||||
Then the order is created
|
||||
And I receive a confirmation email
|
||||
```
|
||||
|
||||
### 매 Test 의 의 use case 별
|
||||
```java
|
||||
@Test
|
||||
void placeOrder_success() {
|
||||
when(inv.check(any())).thenReturn(List.of());
|
||||
when(pay.charge(any(), any())).thenReturn(Charge.ok());
|
||||
|
||||
var result = useCase.execute(req);
|
||||
|
||||
assertInstanceOf(Success.class, result);
|
||||
verify(orders).save(any());
|
||||
}
|
||||
|
||||
@Test
|
||||
void placeOrder_paymentFails() {
|
||||
when(pay.charge(any(), any())).thenReturn(Charge.declined("insufficient"));
|
||||
|
||||
var result = useCase.execute(req);
|
||||
|
||||
assertInstanceOf(PaymentFailed.class, result);
|
||||
verify(orders, never()).save(any());
|
||||
}
|
||||
```
|
||||
|
||||
## 매 결정 기준
|
||||
| 상황 | Approach |
|
||||
|---|---|
|
||||
| 매 enterprise / regulated | 매 Cockburn full template |
|
||||
| 매 agile / startup | 매 User story + acceptance criteria |
|
||||
| 매 Clean Arch impl | 매 Interactor pattern (interface + class) |
|
||||
| 매 stakeholder communication | 매 Use case diagram (high-level) |
|
||||
|
||||
**기본값**: 매 Sea-level use case + Cockburn template (extensions essential) → 매 Interactor.
|
||||
|
||||
## 🔗 Graph
|
||||
- 응용: [[Clean Architecture]] · [[Hexagonal Architecture]]
|
||||
- Adjacent: [[BDD]] · [[Domain-Driven Design]]
|
||||
|
||||
## 🤖 LLM 활용
|
||||
**언제**: 매 새 feature 의 design — 매 main flow + extension 의 enumerate.
|
||||
**언제 X**: 매 매 algorithm / library 의 internal — 매 use case 의 의 user-facing.
|
||||
|
||||
## ❌ 안티패턴
|
||||
- **CRUD use case**: 매 "Create User", "Update User" — 매 implementation 의 leak.
|
||||
- **No extensions**: 매 happy path 의 만 — 매 edge case 의 의 miss.
|
||||
- **Too low level**: 매 "Click button" — 매 fish/clam.
|
||||
- **God use case**: 매 한 use case 의 의 의 모든 의 cover.
|
||||
|
||||
## 🧪 검증 / 중복
|
||||
- Verified — Alistair Cockburn, *Writing Effective Use Cases* (2000); Robert C. Martin, *Clean Architecture*; Ivar Jacobson, *OOSE*.
|
||||
- 신뢰도 A.
|
||||
|
||||
## 🕓 Changelog
|
||||
| 날짜 | 변경 |
|
||||
|---|---|
|
||||
| 2026-05-08 | Phase 1 |
|
||||
| 2026-05-10 | Manual cleanup — Cockburn template + Clean Arch interactor |
|
||||
Reference in New Issue
Block a user