reinforce:wikify - Batch 2: Architecture & Design Patterns (5 artifacts)

2026-05-02 21:25:57 +09:00
parent b85e69a128
commit 2eec9c3ba8
6 changed files with 225 additions and 1 deletions
@@ -17,6 +17,6 @@
  "repelStrength": 10,
  "linkStrength": 1,
  "linkDistance": 250,
-  "scale": 0.0977640602935269,
+  "scale": 0.07596443649899076,
  "close": true
 }
@@ -0,0 +1,44 @@
+---
+id: P-REINFORCE-WIKI-ARCH-CQRS
+title: "명령 조회 책임 분리 (CQRS Pattern)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["CQRS", "Command Query Responsibility Segregation", "하이브리드 데이터 레이어"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 0.95
+tags: ["Architecture", "CQRS", "Eventual_Consistency", "Database_Optimization", "NestJS"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[명령 조회 책임 분리 (CQRS Pattern)]]
+
+## 1. 개요
+CQRS(Command Query Responsibility Segregation)는 애플리케이션 내에서 **데이터 변경(명령, Command)**과 **데이터 조회(조회, Query)**의 책임을 명확히 분리하는 아키텍처 패턴이다. 이를 통해 복잡한 시스템에서 읽기 성능과 쓰기 일관성을 각각 독립적으로 최적화할 수 있다.
+
+## 2. 핵심 메커니즘
+- **Command (명령)**: 시스템의 상태를 변경하는 작업. 비즈니스 규칙과 데이터 무결성 보장이 핵심이다. (예: ORM 활용)
+- **Query (조회)**: 시스템의 상태를 읽는 작업. 성능 최적화와 가벼운 응답이 핵심이다. (예: 경량 SQL 쿼리 빌더 활용)
+- **하이브리드 패턴**: 쓰기에는 무거운 **ORM(Prisma, TypeORM)**을, 읽기에는 가벼운 **SQL 빌더(Kysely, Slonik)**를 사용하는 방식이 실전에서 자주 쓰인다.
+
+## 3. 고급 통합 전략
+- **Hexagonal Architecture**: 헥사고날 구조에서 모듈 간의 횡단 관심사(Cross-cutting)를 처리하고 아키텍처 경계를 관리하기 위해 도입된다.
+- **도메인 이벤트 (Domain Events)**: 상태 변경 시 이벤트를 발행하여 조회 전용 모델을 업데이트하거나 다른 모듈과 통신한다.
+- **결과적 일관성 (Eventual Consistency)**: 읽기와 쓰기 저장소가 분리될 경우, 데이터가 일시적으로 불일치할 수 있으나 최종적으로 일치하게 되는 모델을 수용한다.
+
+## 4. 트레이드오프
+- **장점**: 읽기/쓰기 성능의 독립적 스케일링, 복잡한 비즈니스 로직과 복잡한 조회 요구사항의 분리.
+- **단점**: 시스템 복잡도 증가, 데이터 동기화 관리 비용(Eventual Consistency), 구현 오버헤드.
+
+## 5. 지식 연결 (Related)
+- [[Hexagonal_Architecture]]: CQRS를 수용하기에 최적화된 외부 인터페이스 구조.
+- [[Domain_Driven_Design]]: 명령(Command) 모델의 비즈니스 규칙을 정의하는 방법론.
+- [[Event_Sourcing]]: 상태가 아닌 변경 이벤트를 저장하는 기법 (CQRS와 상보적).
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 고부하 엔터프라이즈 시스템의 성능 최적화를 위한 필수 패턴 정립.
@@ -0,0 +1,44 @@
+---
+id: P-REINFORCE-WIKI-ARCH-CLEAN-ARCHITECTURE
+title: "클린 아키텍처 (Clean Architecture)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["동심원 아키텍처", "Clean Architecture", "의존성 규칙"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Architecture", "Software_Design", "Domain_Driven", "DIP", "Maintainability"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[클린 아키텍처 (Clean Architecture)]]
+
+## 1. 개요
+클린 아키텍처(Clean Architecture)는 로버트 C. 마틴(Robert C. Martin)이 제안한 소프트웨어 설계 패턴으로, **도메인 중심 설계**와 **프레임워크 독립성**을 핵심 원칙으로 삼는다. 시스템을 동심원 형태의 계층으로 나누고, 의존성의 방향을 항상 안쪽(도메인)으로만 향하게 하여 외부 기술 변화에 강건한 구조를 만든다.
+
+## 2. 동심원 계층 구조
+- **Entities (엔티티)**: 가장 안쪽 원. 핵심 비즈니스 규칙을 담은 전사적 객체. 외부 변화에 가장 안정적임.
+- **Use Cases (유스케이스)**: 애플리케이션 특화 비즈니스 규칙. 엔티티를 조정하여 데이터 흐름을 오케스트레이션함.
+- **Interface Adapters (인터페이스 어댑터)**: 외부와 도메인 사이의 번역기. 컨트롤러, 프리젠터, 리포지토리 등이 포함됨.
+- **Frameworks & Drivers**: 가장 바깥쪽 원. DB, 웹 프레임워크, UI 등 세부 사항. 언제든 교체 가능한 플러그인처럼 동작해야 함.
+
+## 3. 핵심 원칙: 의존성 규칙 (Dependency Rule)
+- 소스 코드 의존성은 반드시 **안쪽 원(고수준 정책)**으로만 향해야 한다.
+- 안쪽 원은 바깥쪽 원에 대해 전혀 알지 못해야 하며, 바깥쪽 원의 함수, 클래스, 변수 등을 참조해서는 안 된다.
+
+## 4. 트레이드오프
+- **장점**: 프레임워크 독립성, 테스트 용이성, UI/DB 독립성 확보.
+- **단점**: 단순한 CRUD 애플리케이션에서는 과도한 엔지니어링(Overkill) 및 보일러플레이트 코드 양산 가능성.
+
+## 5. 지식 연결 (Related)
+- [[Hexagonal_Architecture]]: 유사한 철학(포트와 어댑터)을 공유하는 아키텍처.
+- [[Domain_Driven_Design]]: 엔티티와 Bounded Context를 정의하는 방법론.
+- [[SOLID_Principles]]: 클린 아키텍처를 지탱하는 5대 설계 원칙.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 소프트웨어 아키텍처의 표준 모델로서의 정확성 확보.
@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-ARCH-DDD
+title: "도메인 주도 설계 (Domain-Driven Design, DDD)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["DDD", "Domain-Driven Design", "바운디드 컨텍스트"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Architecture", "DDD", "Ubiquitous_Language", "Bounded_Context", "Software_Design"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[도메인 주도 설계 (Domain-Driven Design, DDD)]]
+
+## 1. 개요
+Domain-Driven Design(DDD)은 복잡한 비즈니스 로직을 소프트웨어의 중심에 두고, 기술 팀과 도메인 전문가 간의 협력을 통해 비즈니스 프로세스를 코드로 모델링하는 설계 접근 방식이다. '유비쿼터스 언어'와 '바운디드 컨텍스트'를 통해 시스템의 복잡성을 관리 가능한 수준으로 분해한다.
+
+## 2. 전략적 설계 (Strategic Design)
+- **유비쿼터스 언어 (Ubiquitous Language)**: 개발자와 비즈니스 이해관계자가 공통으로 사용하는 공유 언어. 코드, 문서, 대화에 동일하게 적용됨.
+- **바운디드 컨텍스트 (Bounded Context)**: 특정 도메인 모델이 적용되는 논리적 경계. 각 컨텍스트는 독립적인 모델과 언어를 가짐.
+- **컨텍스트 매핑 (Context Mapping)**: 서로 다른 바운디드 컨텍스트 간의 관계와 통신 방식을 정의.
+
+## 3. 전술적 설계 (Tactical Design)
+- **Entities (엔티티)**: 고유한 식별자를 가지며 상태가 변할 수 있는 객체.
+- **Value Objects (값 객체)**: 고유 식별자 없이 속성 값만으로 정의되는 불변 객체.
+- **Aggregates (애그리거트)**: 데이터 일관성을 보장하기 위해 하나로 묶인 도메인 객체 군집. 애그리거트 루트를 통해서만 접근 가능.
+- **Repositories**: 애그리거트의 영속성을 관리하는 인터페이스.
+
+## 4. 트레이드오프
+- **장점**: 비즈니스 로직의 명확한 가시성, 유지보수성 향상, 유연한 아키텍처 확장(Microservices로의 전환 용이).
+- **단점**: 설계 및 구현 복잡도 상승, 도메인 전문가와의 긴밀한 협업 비용 발생, 단순한 프로젝트에서는 오버헤드.
+
+## 5. 지식 연결 (Related)
+- [[Clean_Architecture]]: 도메인 로직을 외부 인프라로부터 보호하는 아키텍처.
+- [[Microservices_Architecture]]: 바운디드 컨텍스트를 물리적으로 구현하는 일반적인 방식.
+- [[Event_Storming]]: 도메인 모델을 도출하기 위한 협업 워크샵 기법.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 엔터프라이즈 급 소프트웨어 설계의 근간이 되는 DDD의 핵심 원칙 정립.
@@ -0,0 +1,45 @@
+---
+id: P-REINFORCE-WIKI-ARCH-MICROSERVICES
+title: "마이크로서비스 아키텍처 (Microservices Architecture)"
+category: "10_Wiki/🏗️ Topics_Arch"
+status: verified
+canonical_id: ""
+aliases: ["MSA", "Microservices", "분산 시스템 아키텍처"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["Architecture", "MSA", "Cloud_Native", "Serverless", "Scalability"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[마이크로서비스 아키텍처 (Microservices Architecture)]]
+
+## 1. 개요
+마이크로서비스 아키텍처(Microservices Architecture, MSA)는 대규모 애플리케이션을 독립적으로 배포 및 확장이 가능한 작은 서비스 단위로 분할하여 구축하는 방식이다. 각 서비스는 특정 비즈니스 기능을 수행하며, 네트워크를 통해 상호 통신한다.
+
+## 2. 핵심 특징
+- **독립적 배포/확장**: 전체 시스템 중 특정 서비스만 개별적으로 업데이트하거나 트래픽에 따라 탄력적으로 확장(Scaling) 가능.
+- **클라우드 네이티브 결합**: 컨테이너(Docker/K8s) 및 서버리스(AWS Lambda 등) 환경과 결합하여 운영 효율성 극대화.
+- **기술 다양성 (Polyglot)**: 각 서비스의 특성에 맞는 최적의 기술 스택(Node.js, Java, Go 등)을 개별적으로 선택 가능.
+- **Bounded Context 기반**: DDD의 바운디드 컨텍스트 단위를 물리적 서비스 경계로 삼아 서비스 간 간섭 최소화.
+
+## 3. 구현 방식
+- **통신 패턴**: REST API(동기) 및 메시지 큐(비동기, RabbitMQ/Kafka)를 활용한 이벤트 기반 아키텍처.
+- **프레임워크**: Java 환경의 **Spring Boot**, Node.js 환경의 **Express/NestJS** 등이 주로 사용됨.
+- **JAMstack 연동**: 백엔드 기능을 API 형태로 제공하여 프론트엔드와 완벽히 분리된 구조 구축.
+
+## 4. 트레이드오프
+- **장점**: 개발 생산성 향상, 장애 격리(Fault Isolation), 빠른 시장 출시(Time-to-Market).
+- **단점**: 분산 시스템 통신 복잡성 증가, 데이터 일관성 관리(Eventual Consistency)의 어려움, 모니터링 및 로깅의 복잡도 상승.
+
+## 5. 지식 연결 (Related)
+- [[Hexagonal_Architecture]]: 서비스 내부 구조를 외부 기술과 격리하는 기법.
+- [[Serverless_Computing]]: MSA를 구현하기 위한 탄력적 인프라 환경.
+- [[Domain_Driven_Design]]: 서비스 경계(Bounded Context)를 획정하기 위한 설계 방법론.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 클라우드 시대의 표준 아키텍처로서의 MSA 핵심 가치 및 구조 정립.
@@ -0,0 +1,46 @@
+---
+id: P-REINFORCE-WIKI-DEV-SOLID
+title: "객체 지향 설계 5원칙 (SOLID Principles)"
+category: "10_Wiki/💻 Topics_Dev"
+status: verified
+canonical_id: ""
+aliases: ["SOLID", "객체 지향 설계 원칙", "클린 코드 원칙"]
+duplicate_of: ""
+source_trust_level: A
+confidence_score: 1.0
+tags: ["OOP", "SOLID", "Clean_Code", "Design_Principles", "Maintainability"]
+raw_sources: ["Datacollector_Export_2026-05-02"]
+last_reinforced: 2026-05-02
+github_commit: ""
+---
+
+# [[객체 지향 설계 5원칙 (SOLID Principles)]]
+
+## 1. 개요
+SOLID 원칙은 객체 지향 프로그래밍에서 소프트웨어 설계를 더욱 유연하고 유지보수하기 좋게 만들기 위해 고안된 5가지 설계 원칙의 집합이다. 로버트 C. 마틴에 의해 체계화되었으며, 결합도를 낮추고 응집도를 높이는 견고한 코드베이스의 기초가 된다.
+
+## 2. 5대 원칙 (Five Principles)
+1.  **SRP (Single Responsibility Principle, 단일 책임 원칙)**: 클래스는 단 하나의 변경 이유만 가져야 한다. (하나의 클래스는 하나의 역할만 수행)
+2.  **OCP (Open/Closed Principle, 개방-폐쇄 원칙)**: 확장에는 열려 있어야 하고, 수정에는 닫혀 있어야 한다. (기존 코드 변경 없이 기능 추가 가능해야 함)
+3.  **LSP (Liskov Substitution Principle, 리스코프 치환 원칙)**: 하위 타입은 언제나 자신의 상위 타입으로 교체될 수 있어야 한다.
+4.  **ISP (Interface Segregation Principle, 인터페이스 분리 원칙)**: 자신이 사용하지 않는 메서드에 의존하도록 강제해서는 안 된다. (구체적인 여러 인터페이스가 범용 하나보다 낫다)
+5.  **DIP (Dependency Inversion Principle, 의존성 역전 원칙)**: 고수준 모듈은 저수준 모듈에 의존해서는 안 되며, 둘 다 추상화에 의존해야 한다.
+
+## 3. 실전 적용 팁
+- **SRP부터 시작**: 클래스의 역할을 분리하는 것만으로도 코드의 복잡성이 획기적으로 줄어든다.
+- **인터페이스 우선 설계**: 구현체보다 인터페이스(Contract)를 먼저 정의하여 자연스럽게 OCP와 DIP를 준수하도록 유도한다.
+- **점진적 리팩토링**: 레거시 코드를 한꺼번에 바꾸기보다 신규 기능 추가 시 해당 영역에 원칙을 적용하며 개선한다.
+
+## 4. 트레이드오프
+- **장점**: 코드 재사용성 향상, 테스트 용이성, 변화에 유연한 대응.
+- **단점**: 인터페이스 및 추상화 도입으로 인해 초기 설계 비용과 보일러플레이트 코드 증가.
+
+## 5. 지식 연결 (Related)
+- [[Clean_Architecture]]: SOLID 원칙이 대규모 시스템 레이어 분리에 적용된 결과물.
+- [[Dependency_Injection]]: DIP를 실현하기 위한 핵심 기술적 수단.
+- [[Design_Patterns]]: SOLID 원칙을 특정 문제 해결에 맞게 구체화한 검증된 패턴들.
+
+## 🧪 검증 상태 (Validation)
+- **정보 상태**: 검증 완료 (Verified)
+- **출처 신뢰도**: A
+- **검토 이유**: 소프트웨어 공학의 정수인 SOLID 원칙의 명확한 정의와 실천 방안 수록.