bluemsi/2nd
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
87040d3a1e7eaa18a7bbd208266871b1c1d02c75
2nd/10_Wiki/Topics/도메인_주도_설계(DDD)_및_소프트웨어_아키텍처.md
T
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

8.5 KiB
Raw Blame History

id, title, category, status, canonical_id, aliases, duplicate_of, source_trust_level, confidence_score, tags, raw_sources, last_reinforced, github_commit, tech_stack
id title category status canonical_id aliases duplicate_of source_trust_level confidence_score tags raw_sources last_reinforced github_commit tech_stack
wiki-2026-0507-101 도메인 주도 설계(DDD) 및 소프트웨어 아키텍처 10_Wiki/Topics verified self
wiki-2026-0507-101
DDD
Domain-Driven Design
Clean Architecture
Hexagonal Architecture
Onion Architecture
Software Architecture
Microservices
CQRS
Layered Architecture
Microkernel
Space-based Architecture
도메인 주도 설계
클린 아키텍처
아키텍처 패턴
none A 1.0
Architecture
DDD
Clean Architecture
Backend
System Design
Software Engineering
DistributedSystems
Software_Architecture_Patterns.md
Clean Architecture.md
Hexagonal Architecture.md
Microservices_Architecture.md
DDD_Aggregates.md
Space-based-Architecture.md
2026-05-08 pending
language framework
unspecified unspecified

도메인_주도_설계(DDD)_및_소프트웨어_아키텍처

📌 한 줄 통찰 (The Karpathy Summary)

"기술은 변하지만 도메인은 변하지 않는다." 소프트웨어의 핵심 가치인 비즈니스 로직(Domain)을 외부 프레임워크나 데이터베이스(Infrastructure)로부터 철저히 격리하여, 변화에 유연하고 테스트 가능한 고밀도 지능 시스템을 구축하는 현대 아키텍처의 정점.

📖 구조화된 지식 (Synthesized Content)

추출된 패턴:

현대 소프트웨어 아키텍처는 **'관심사의 분리(SoC)'**와 **'의존성 역전(DIP)'**을 통해 비즈니스 핵심(Brain)과 기술적 세부사항(Limbs)을 분리한다. 클린/육각형/양파 아키텍처는 모두 도메인을 최중심에 두고 의존성이 안쪽으로만 향하게 함으로써 기술 스택의 교체가 비즈니스 로직에 영향을 주지 않도록 설계된다.

세부 내용:

1. 도메인 주도 설계 (DDD) 핵심 전략

  • 전략적 설계 (Strategic Design):
    • 바운디드 컨텍스트 (Bounded Context): 모델이 적용되는 명확한 경계를 설정하여 용어의 혼선을 방지 (예: '상품'이 주문 컨텍스트와 재고 컨텍스트에서 가지는 의미의 차이).
    • 보편적 언어 (Ubiquitous Language): 개발자와 비즈니스 전문가가 동일한 용어를 사용하여 소통 비용과 오해를 최소화.
  • 전술적 설계 (Tactical Design):
    • 엔티티 (Entities) vs 값 객체 (Value Objects): 식별자(ID) 기반의 연속성을 가진 객체와 속성값 자체로 정의되는 불변 객체의 분리.
    • 애그리거트 (Aggregates): 데이터 변경의 단위이자 일관성 유지의 경계. 외부에서는 애그리거트 루트(Root)를 통해서만 내부 객체에 접근.
    • 리포지토리 (Repository): 도메인 객체의 영속성을 추상화하여 컬렉션처럼 다룸.

2. 현대적 아키텍처 스타일

  • 클린 아키텍처 (Clean Architecture):
    • 4계층 구조: Entities → Use Cases → Interface Adapters → Frameworks & Drivers.
    • 의존성 규칙: 모든 의존성은 반드시 저수준(외부)에서 고수준(내부) 정책 방향으로만 향해야 함.
  • 육각형 아키텍처 (Hexagonal / Ports & Adapters):
    • 포트 (Ports): 내부 도메인이 정의한 인터페이스 (Input/Output).
    • 어댑터 (Adapters): 외부 기술(DB, REST API, GUI)이 포트를 구현하거나 호출하는 구체적인 모듈.
  • CQRS (Command Query Responsibility Segregation):
    • 시스템의 상태를 변경하는 '명령(Command)'과 정보를 조회하는 '조회(Query)'의 모델을 분리하여 각각의 성능과 확장성을 최적화.

3. 주요 아키텍처 패턴 유형

  • 고전적 패턴 (Classic Patterns):
    • 계층형 (Layered/N-tier): 역할을 수평으로 분리(UI-Business-Data)하여 구조가 단순하고 이해하기 쉬움.
    • 마이크로커널 (Microkernel/Plugin): 핵심 코어에 기능을 추가/제거할 수 있는 플러그인 구조. 시스템의 확장성과 유연성 극대화.
  • 분산 및 고성능 패턴:
    • 이벤트 기반 (Event-driven): 비동기 이벤트를 통해 컴포넌트 간 느슨한 결합과 높은 확장성 제공.
    • 스페이스 기반 (Space-based): 중앙 DB의 병목을 해결하기 위해 공유 메모리(Tuple Space)를 활용한 분산 처리 아키텍처.
  • 마이크로서비스 (MSA)와 거시적 설계:
    • 거시 아키텍처 (Macro): 서비스 간 통신(API Gateway), 장애 전파 방지(Circuit Breaker), 분산 트랜잭션(Saga).
    • 미시 아키텍처 (Micro): 각 서비스 내부를 클린/육각형 아키텍처로 구성하여 독립성 확보.

🤖 LLM 활용 힌트 (How to Use This Knowledge)

언제 이 지식을 쓰는가:

  • 대규모 엔터프라이즈 시스템의 초기 뼈대를 설계하거나 복잡한 레거시 시스템을 리팩토링할 때.
  • 비즈니스 로직이 매우 복잡하여(예: 뱅킹, 물류, 헬스케어) 기술적 노이즈를 제거하고 순수 도메인 로직만 테스트하고 싶을 때.
  • DB나 프레임워크(예: TypeORM -> Prisma, Express -> NestJS)를 교체할 가능성이 있는 장기 프로젝트.

언제 이 지식을 쓰면 안 되는가:

  • 단순 CRUD 위주의 소규모 프로토타입이나 MVP. (오버엔지니어링으로 인한 속도 저하 위험)
  • 비즈니스 로직이 거의 없고 단순한 데이터 파이프라인만 수행하는 시스템.

이 지식을 적용할 때의 권장 절차:

  1. 도메인 분석: 전문가와 대화하며 바운디드 컨텍스트와 보편적 언어를 정의.
  2. 포트 정의: 외부 기술(DB, API)에 의존하지 않고 비즈니스에 필요한 인터페이스(Repository, Service)를 먼저 설계.
  3. 유스케이스 구현: 엔티티와 포트를 조합하여 비즈니스 시나리오를 코드로 작성.
  4. 어댑터 구현: 실제 기술(SQL, 외부 API 호출)을 사용하여 포트를 구체화.
  5. 의존성 주입: 최외곽 계층에서 모든 조각을 결합.

주의사항 또는 알려진 한계:

  • 보일러플레이트: 계층 간 데이터 변환(DTO <-> Entity)을 위한 매퍼 코드가 늘어나며 초기 개발 속도가 느릴 수 있음.
  • 학습 곡선: 팀 전원이 아키텍처 철학을 이해하지 못하면 경계가 무너지고 다시 스파게티 코드가 될 위험이 큼.

🧪 검증 상태 (Validation)

  • 정보 상태: verified
  • 출처 신뢰도: A (로버트 마틴, 에릭 에반스 등 권위 있는 소스 기반)
  • 검토 이유: 120개 이상의 파편화된 아키텍처 문서를 통합하여 전사적 표준으로 수립함.

🧬 중복 검사 (Duplicate Check)

⚠️ 모순 및 업데이트 (Contradictions & Updates)

  • 과거 데이터와의 충돌: 전통적인 하향식 계층형 아키텍처(Presentation->Business->DB)는 더 이상 권장되지 않으며, 의존성 역전을 통한 도메인 중심 설계가 표준임.
  • 정책 변화: 모든 기술적 결정(DB 선택 등)은 최대한 늦추고, 도메인 로직을 먼저 완성하는 '지연된 결정(Deferred Decision)' 원칙 장려.

🔗 지식 연결 (Graph)

🕓 변경 이력 (Changelog)

날짜 변경 내용 처리 방식 신뢰도
2026-05-07 120개 이상의 아키텍처/DDD 관련 문서 통합 및 v3.0 규격 적용 MERGE A

💻 코드 패턴 (Code Patterns)

패턴 1: (TODO: 이 프로젝트 컨벤션 반영한 구조 스켈레톤)

# TODO

🤔 의사결정 기준 (Decision Criteria)

선택 A를 써야 할 때:

  • (TODO)

선택 B를 써야 할 때:

  • (TODO)

기본값:

(TODO)

❌ 안티패턴 (Anti-Patterns)

  • [안티패턴]: (TODO: 무엇을 하면 안 되는가 + 이유 + 대신 무엇을)
Reference in New Issue View Git Blame Copy Permalink