2nd/10_Wiki/Topics/Domain_Programming/DevOps_and_Security/유스케이스 (Use Cases).md

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, verification_status, tags, raw_sources, last_reinforced, github_commit, tech_stack

id	title	category	status	canonical_id	aliases	duplicate_of	source_trust_level	confidence_score	verification_status	tags	raw_sources	last_reinforced	github_commit	tech_stack
wiki-2026-0508-유스케이스-use-cases	유스케이스 (Use Cases)	10_Wiki/Topics	verified	self	Use Cases 유스케이스 Use Case Analysis	none	A	0.9	applied	requirements analysis uml agile design		2026-05-10	pending	language framework any 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)

# 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)

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)

@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

# 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 별

@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