---
# 🏛️ 바이브 모델링 & 제조 공정 통합 핸드북 (최종본)
## [PART 1] 설계 전처리: 바이브 모델링 3단계
1. **Vibe Sync**: 시스템 페르소나와 도메인 경계 정의.
2. **Dynamic Skeleton**: DB 설계 전, 유즈케이스 단위의 **액티비티(Flow)** 설계 우선.
3. **Vibe Iteration**: 액티비티를 지탱할 **풍부한 도메인 모델(Rich Domain Model)** 속성과 규칙 할당.
---
## [PART 2] 제조 공정: 5단계 모듈 레이어 및 격리 수칙
시스템은 독립적인 **모듈(Module)** 단위로 구성되며, 각 레이어는 엄격한 **가시성(Visibility)**을 가집니다.
| 단계 | 패키지 | 역할 및 구성 요소 | 가시성 및 외부 모듈 참조 규칙 |
| --- | --- | --- | --- |
| **1단계** | **application** | **Activity(Usecase)**, DTO, 이벤트 | **Public.** 모듈의 유일한 입구. 외부 모듈은 여기만 참조 가능. |
| **2단계** | **model** | **Aggregate**, Entity, Domain Logic | **Internal.** 철저히 격리. 외부에서 엔티티 직접 접근 불가. |
| **3단계** | **port** | Repository & 외부 연동 인터페이스 | **Mixed.** 비즈니스 접점은 공개, DB 전용은 격리. |
| **4단계** | **infra** | Port 구현체(Adapter), DB 설정 | **Internal.** 기술적 세부사항이므로 외부 노출 금지. |
| **5단계** | **api** | **Service(Facade)**, Controller | **Internal.** 웹 진입점. 타 모듈에서 직접 호출 불가. |
### 💡 모듈 관리 및 구현 수칙
* **성벽 원칙**: `application`(1단계)은 성문이며, 그 외 모든 레이어는 성벽 안쪽(Internal)에 숨깁니다.
* **Service Facade**: `api`(5단계)의 `Service`는 관련 Activity들을 필드로 모아 컨텍스트 경계를 형성하며, 컨트롤러는 이 서비스만 바라봅니다.
* **Identity 전파**: 컨트롤러는 인증 정보에서 식별자(userId)만 추출하여 Activity의 `operator` 인자로 넘깁니다.
* **데이터 접근**: 타 모듈 테이블은 `SELECT`만 허용하며, 반드시 자신의 `Port`를 통해 전용 VO로 매핑하여 가져옵니다.
---
## [PART 3] 데이터 표준화 및 응답 규격
1. **실용적 DTO**: 과도한 추상화(`Payload`, `Search`, `Vo`)를 폐기하고 구체적인 **Record**를 사용합니다.
* **Request**: `@Valid`를 포함한 독립 Record.
* **Response**: 도메인으로부터 생성되는 정적 팩토리 메서드(`from()`) 소유.
2. **공통 응답 (Global Envelope)**: `Success`/`Fail` 규격을 유지하며, `ResponseBodyAdvice`를 통해 자동 포장합니다.
---
## [PART 4] 현대적 테스트 수칙
* **BDD 스타일**: `BDDMockito.given()`으로 비즈니스 시나리오를 검증합니다.
* **MockMvcTester**: 최신 `assertThat()` 체이닝을 통해 컨트롤러의 응답 규격을 검증합니다.
* **Infra Test**: `Testcontainers`로 실제 PostgreSQL 환경에서 SQL 무결성(Upsert 등)을 확인합니다.
---
## 📝 최종 설계 철학: "Pragmatic Clean Architecture"
> **"복잡한 인터페이스보다 명확한 바운더리를, 거창한 추상화보다 실용적인 모듈화를 우선한다."**
> 1. 모든 코드는 테스트 가능해야 한다.
> 2. 기술은 도메인을 보호하기 위한 수단일 뿐이다.
> 3. 모듈 간 결합은 DB 수준에서 실용성을 찾되, 코드 수준에서는 철저히 격리한다.
>
>
댓글
댓글 쓰기