Files
2nd/10_Wiki/Topics/DevOps_and_Security/엔터프라이즈 소프트웨어 시스템 설계.md
koriweb d8a80f6272 chore(wiki): dangling 링크 canonical 정규화 (768파일/1200건)
이름만 다른(표기 변형) [[위키링크]]를 대상 문서의 canonical 제목으로 치환해
끊겼던 1,200개 링크를 연결. 제목/파일명 정규화 일치만 적용하고 별칭 매칭은
과병합 위험으로 제외(애매성 가드). 원본은 _link_reconcile_backup/ 에 백업.
도구: Datacollect/scripts/link_reconcile_apply.mjs

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-08 12:24:15 +09:00

5.5 KiB

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-엔터프라이즈-소프트웨어-시스템-설계 엔터프라이즈 소프트웨어 시스템 설계 10_Wiki/Topics verified self
Enterprise Software Design
Enterprise Architecture
none A 0.9 applied
enterprise
architecture
systems-design
scalability
2026-05-10 pending
language framework
java spring-boot

엔터프라이즈 소프트웨어 시스템 설계

매 한 줄

"매 large-scale, mission-critical, long-lived". 매 enterprise software 의 multi-team / multi-decade scale 의 system 의 design — 매 reliability, security, compliance, integration 의 first-class concern. 매 2026 의 cloud-native + 매 legacy mainframe 의 hybrid 의 reality.

매 핵심

매 Enterprise 의 specific concerns

  • Scale: 매 thousands of concurrent users, TB+ data.
  • Longevity: 매 10-30년 의 lifespan — 매 maintainability 의 critical.
  • Compliance: 매 SOX, GDPR, HIPAA, PCI-DSS.
  • Integration: 매 N legacy system 의 talk to.
  • Multi-team: 매 Conway's law — 매 org structure 가 architecture 의 reflect.

매 Architecture layers (전통)

  1. Presentation — UI / API.
  2. Application — orchestration, use cases.
  3. Domain — business logic.
  4. Infrastructure — persistence, messaging, external.

매 2026 modern stack

  • Frontend: React / Next.js, micro-frontends.
  • API: GraphQL Federation, gRPC, REST.
  • Service: Microservices (Java/Spring Boot, Go, Kotlin).
  • Data: PostgreSQL, Kafka, Snowflake / Databricks.
  • Platform: Kubernetes, Istio, ArgoCD.
  • Observability: OpenTelemetry, Datadog, Grafana.

매 Cross-cutting concerns

  • AuthN/AuthZ (OAuth2, OIDC, mTLS)
  • Audit logging
  • Distributed tracing
  • Rate limiting, circuit breakers
  • Multi-tenancy

💻 패턴

매 Hexagonal architecture

// 매 Domain — 매 framework 의존 X
public class OrderService {
    private final OrderRepository repo;     // port
    private final PaymentGateway payment;   // port

    public Order place(PlaceOrderCommand cmd) {
        var order = Order.create(cmd);
        payment.charge(cmd.payment());
        return repo.save(order);
    }
}

매 CQRS + Event Sourcing

// Command side
@Component
class OrderCommandHandler {
    public void handle(PlaceOrder cmd) {
        var events = OrderAggregate.place(cmd);
        eventStore.append(cmd.orderId(), events);
        bus.publish(events);
    }
}

// Query side
@Component
class OrderProjection {
    @KafkaListener(topics = "order-events")
    public void on(OrderPlaced e) { readModel.upsert(e); }
}

매 Saga (distributed transaction)

@Saga
public class OrderSaga {
    @StartSaga
    public void on(OrderPlaced e) {
        send(new ReserveInventory(e.orderId()));
    }

    @SagaEventHandler
    public void on(InventoryReserved e) {
        send(new ChargePayment(e.orderId()));
    }

    @SagaEventHandler
    public void on(PaymentFailed e) {
        send(new ReleaseInventory(e.orderId()));
        end();
    }
}

매 Strangler fig (legacy migration)

# 매 Gateway routing — 매 old → new 의 incremental
routes:
  - path: /api/orders/*
    backend: new-order-service  # 매 migrated
  - path: /api/billing/*
    backend: legacy-mainframe   # 매 still legacy

매 Multi-tenancy 의 patterns

// 매 Row-level — 매 cheapest
@Entity
class Order {
    @Column UUID tenantId;
    // 매 every query 의 tenant filter
}

// 매 Schema-per-tenant — 매 isolation
DataSource ds = tenantRouter.resolve(currentTenant());

// 매 DB-per-tenant — 매 strongest, costliest

매 BFF (Backend for Frontend)

services:
  bff-mobile:    # 매 mobile 최적화 payload
  bff-web:       # 매 web 최적화
  bff-partner:   # 매 B2B integration
  # 매 모두 매 동일 backend service 의 aggregate

매 결정 기준

상황 Approach
매 startup, ≤10 dev 매 Modular monolith
매 scale-up, multi-team 매 Microservices + DDD
매 legacy 의 modernization 매 Strangler fig
매 strict audit / replay 매 Event sourcing
매 read-heavy + complex write 매 CQRS

기본값: 매 modular monolith 부터 → 매 pain point 별 의 carve out.

🔗 Graph

🤖 LLM 활용

언제: 매 large-scale system design interview / RFC / ADR 작성 시. 언제 X: 매 small CRUD app — 매 over-engineering 의 risk.

안티패턴

  • Distributed monolith: 매 microservice 의 모양 의 만 갖춘 의 tight coupling.
  • Big bang rewrite: 매 legacy 의 한 번에 의 replace — 매 거의 fail.
  • Anemic domain: 매 logic 의 service layer 의 만 — 매 domain object 의 의 data bag.
  • Shared database: 매 microservice 간 의 DB 공유 → 매 hidden coupling.

🧪 검증 / 중복

  • Verified — Martin Fowler, Patterns of Enterprise Application Architecture; Eric Evans, Domain-Driven Design; Sam Newman, Building Microservices (2nd ed).
  • 신뢰도 A.

🕓 Changelog

날짜 변경
2026-05-08 Phase 1
2026-05-10 Manual cleanup — enterprise architecture patterns + 2026 stack