# apply-architecture

> 전체적인 파일들을 사용자가 지정한 아키텍쳐를 기반으로 구조화 할때 사용합니다. 각각의 파일명들은 명확하게 정의되게하며 각 파일들 테스트에 용이하도록 의존성이 약화되게 합니다.

- Author: arslanRedemar
- Repository: arslanRedemar/mettaton
- Version: 20260131214435
- Stars: 0
- Forks: 0
- Last Updated: 2026-02-06
- Source: https://github.com/arslanRedemar/mettaton
- Web: https://mule.run/skillshub/@@arslanRedemar/mettaton~apply-architecture:20260131214435

---

---
name: apply-architecture
description: 전체적인 파일들을 사용자가 지정한 아키텍쳐를 기반으로 구조화 할때 사용합니다. 각각의 파일명들은 명확하게 정의되게하며 각 파일들 테스트에 용이하도록 의존성이 약화되게 합니다.
---
## Clean Architecture 핵심 원칙 요약

> 소스 코드 의존성은 **안쪽으로만** 향해야 한다. 내부 원은 외부 원에 대해 아무것도 알 수 없다.

```
┌─────────────────────────────────────────┐
│         Frameworks & Drivers            │  ← 가장 바깥 (메커니즘)
│  ┌───────────────────────────────────┐  │
│  │       Interface Adapters          │  │
│  │  ┌─────────────────────────────┐  │  │
│  │  │        Use Cases            │  │  │
│  │  │  ┌───────────────────────┐  │  │  │
│  │  │  │      Entities         │  │  │  │  ← 가장 안쪽 (정책)
│  │  │  └───────────────────────┘  │  │  │
│  │  └─────────────────────────────┘  │  │
│  └───────────────────────────────────┘  │
└─────────────────────────────────────────┘
        의존성 방향 →→→ 안쪽으로
```

### Clean Architecture 레이어 설명

| 레이어 | 역할 |
|--------|------|
| **Entities** | 전사적 비즈니스 규칙을 캡슐화. 메서드가 있는 객체 또는 데이터 구조 |
| **Use Cases** | 엔티티로/부터 데이터 흐름을 조율하고 비즈니스 규칙 실행을 지시 |
| **Interface Adapters** | 유스케이스/엔티티 형식 ↔ 외부 형식(DB, Web) 변환 |
| **Frameworks & Drivers** | UI, DB, 디바이스 등을 내부 원에 연결하는 접착 코드 |

---

## Clean Architecture 폴더 구조

```
core/
├── config/             # 환경변수 및 앱 설정
├── di/                 # 의존성 주입 설정
├── errors/             # 커스텀 에러/예외 클래스
├── types/              # 공통 타입 정의
└── utils/              # 공통 유틸리티

src/
├── data/                       # 데이터 레이어 (외부 시스템 구현)
│   ├── datasource/            # DB 연결 및 초기화
│   ├── mappers/               # Entity ↔ Model 변환
│   ├── models/                # DB 모델 (테이블 스키마)
│   └── repositories/          # 레포지토리 구현체
│
├── domain/                     # 도메인 레이어 (핵심 비즈니스 로직)
│   ├── entities/              # 비즈니스 엔티티
│   ├── repositories/          # 레포지토리 인터페이스 (추상화)
│   └── usecases/              # 비즈니스 유스케이스
│
└── presentation/               # 프레젠테이션 레이어 (외부 입력/출력)
    ├── controllers/           # 요청 핸들러
    ├── dto/                   # Data Transfer Objects
    ├── interfaces/            # UI 인터페이스
    └── views/                 # 응답 뷰/포맷터

tests/
├── unit/                      # 단위 테스트
└── integration/               # 통합 테스트
```

---

## 의존성 규칙

```
Presentation → Domain ← Data
                ↑
              Core
```

- **Domain**은 어떤 레이어에도 의존하지 않음
- **Data**는 Domain의 인터페이스를 구현 (의존성 역전)
- **Presentation**은 Domain의 Usecase를 호출
- **Core**는 모든 레이어에서 사용 가능

---

## 아키텍처 특성

### Simple (단순한 아키텍처)
- **일관된 설계 결정**: 하나의 문제에 하나의 해결책
- **최소한의 개념/기술**: 적은 수의 개념과 기술 사용
- **적은 상호작용**: 상호작용이 적을수록 단순함
- **작은 크기**: 큰 시스템은 작은 부분들로 구성

### Flexible (유연한 아키텍처)
- **관심사 분리**: 기능 간 겹침을 최소화하여 자유롭게 조합
- **추상화**: 구현과 아이디어 분리 (과도한 추상화 주의)
- **슬림한 인터페이스**: 뚱뚱한 인터페이스는 강한 결합 유발
- **상속보다 조합**: 상속은 부모-자식 간 결합 증가
- **순환 없는 의존성**: 의존성 그래프에 사이클 없음

### Evolvable (진화 가능한 아키텍처)
- **현재 요구사항에 맞춤**: 미래가 아닌 현재 필요에 맞춤
- **막다른 길 없음**: 확장/적응 가능한 구조
- **아키텍처 불가지론적 컴포넌트**: 컴포넌트가 아키텍처에 의존하지 않음
- **희생적 아키텍처**: 수명이 다하면 버리고 새로 시작
- **롤링 리팩토링**: 새 버전 도입 시 이전 버전을 단계적으로 제거

### Agile (애자일 아키텍처)
- **빠른 변경 허용**: 유연성과 진화가능성을 통해
- **언제든 검증 가능**: 모든 품질 측면을 언제든 검증
- **빠른 배포**: 지속적이고 빠른 배포 지원
- **항상 동작**: 제한된 기능이라도 항상 동작하는 상태 유지

---

## 우선순위 원칙

| 우선 | 보다 |
|------|------|
| 단순함 | 일반화 |
| 하드코딩 | 설정 가능 |
| 사용 | 재사용 |
| 동작 | 최적화 |
| 품질 속성 | 기능 요구사항 |
| 작은 시스템 조합 | 하나의 큰 시스템 |

---

## 아키텍처 워크플로우

```
1. Context (컨텍스트)
   → 시스템 경계 정의, 외부 서비스 식별

2. Break down (분해)
   → 관심사 분리와 단일 책임 원칙 적용

3. Communication (통신)
   → 데이터 흐름, 채널 속성 (동기/비동기, 신뢰성)

4. Repeat (반복)
   → 각 부분에 대해 1-3 반복
```

### 결정 미루기 전략
- **추상화**: 세부사항을 숨기고 시뮬레이션/페이크 사용
- **단순화**: 문제를 단순화하여 결정하고 진행
- **의도적 무시**: 더 많은 지식이 쌓일 때까지 대기
- **결정 위임**: 다른 부분에 책임 위임

---

## 아키텍처 안티패턴 (Smells)

| 패턴 | 설명 |
|------|------|
| **Overlayered** | 레이어 위에 레이어... 추상화 없이 보일러플레이트만 증가 |
| **Overabstraction** | 너무 추상적이어서 이해 불가 |
| **Overconfigurability** | 모든 것이 설정 가능 (결정 회피) |
| **Overkill** | 단순한 문제에 복잡한 해결책 |
| **Futuristic** | 미래 변경을 과도하게 예측 |
| **Technology enthusiastic** | 새 기술을 위한 새 기술 도입 |
| **Paper tiger** | UML 다이어그램에만 존재하는 아키텍처 |
| **Split brain** | 같은 데이터에 대한 소유권 분쟁 |

---

## 아키텍처 고려사항

- **Persistence**: 데이터 형태, 트랜잭션, 복제, 동시성
- **Communication**: 동기/비동기, 신뢰성, 지연시간
- **Scaling**: 스레드/프로세스/머신, 가용성, 일관성
- **Security**: 인증, 권한, 암호화
- **Versioning**: SemVer, 하위 호환성
- **Distribution**: 분산 컴퓨팅의 오류 인식

---

## 팁

- 기술이 아닌 **개념**으로 시작
- 대부분의 경우 **영속성은 부차적** 고려사항
- **환경과 분리** 설계
- 아키텍처 패턴은 **영감**으로 사용, 해결책으로 적용하지 않음
- 프로토타입과 PoC로 **리스크를 줄이고 지식을 빠르게 축적**

---

## 참고 자료

- [Clean-Architecture-CheatSheet.pdf](References/Clean-Architecture-CheatSheet.pdf) - bbv Software Services