소리치는 아키텍처 - 개발공정 - 유스케이스 구현

### 목차
- [(서문) 개발공정](https://ohhoonim.blogspot.com/2024/02/blog-post_62.html)
- [1. 이벤트스토밍](https://ohhoonim.blogspot.com/2024/02/blog-post_47.html)
- [2. 유스케이스 구현](https://ohhoonim.blogspot.com/2024/02/blog-post_92.html) <- 현재문서
- [3. 인프라 테스트](https://ohhoonim.blogspot.com/2024/02/blog-post_39.html) 
- [4. UI 구현](https://ohhoonim.blogspot.com/2024/02/ui_21.html)
## abstract
[[이벤트스토밍]]에서 발견된 유스케이스를 코드로 설계 구현 한다. 일반적인 설계와 다른 점은 docx와 같은 문서로 하지 않고 TDD방식으로 설계구현을 한다는 것이다. TDD는 Test Driven Development 의 약자이지만 'Driven'의 의미를 고찰해볼때 도메인 설계를 이끌어내는 유스케이스 구현이라는 의미로 이 공정에서는 사용된다. 도메인 설계를 이끌어 낸다는 의미는 차후 도메인에 대한 표준 모델 또는 참조 모델을 도출해내려 하는 것이 최종 목표이다. 유스케이스를 구현하는 모듈은 모든 인프라에 최대한 독립적으로 구성되어야 한다. 
## tool
- TDD : Test Driven Development 의 약자로 테스트 코드를 작성하면서 동작하는 코드를 완성시켜가는 개발 방법이다. xUnit test로도 알려진 JUnit test framework이 TDD를 구현한 대표적인 프레임워크이다. 
- IDE : Integration Development Environment의 약자로 통합개발도구를 의미한다. Java진영에는 대표적으로 Eclipse, IntelliJ, VSCode 등이 존재한다. 
- Hexagoanl Archietecture : 일명 “포트-어뎁터” 패턴으로도 알려져 있다. “클린 아키텍처" [^clean-archietecture]에서 제시한 사례 중 하나이며, 도메인을 인프라와 독립적으로 개발 할 수 있는 아키텍처이다. 
- Java : 객체지향프로그래밍을 지원하는 대표적인 언어이다. 기업용 솔루션을 구축할 때 전 세계에서 가장 많이 사용되고 있다. 
- Spring framework : Spring framework의 메인기능은 Inversion of Control (IoC) container 이다. IoC가 무엇인지 자세히 알고 싶다면 OOP 설계원칙인 SOLID를 학습하는 것으로 시작하길 권장한다. 

[^clean-archietecture]: [[Clean Architecture|Robert C. Martin, "Clean Architecture: A Craftsman's Guide to Software Structure and Design", (Pearson, 2017)]]
## activity
- [[이벤트스토밍]]에서 도출된 유스케이스는 아직 덜 정제된 것일 가능성이 크다. 유스케이스 설계구현을 위한  정제작업을 위해 다음 사항들을 고려해본다. 
	- command를 시작점으로 끊김없이 이어져야하는 event + command 를 파악하고, 끊김이 발생하는 command 앞에 경계를 나눈다. 끊기지 말아야할 command는 업무 흐름에서 trigger로 동작하는 경우가 많다.
	- external system은 trigger형 command가 될 수도 있다. (외부시스템에서 주문이 들어오는 경우)
	- 적절히 경계가 그어졌다면 각 경계단위로 유스케이스명을 정하고, 간단한 설명을 적는다.
	- 하나의 유스케이스는 여러개의 command를 가질 수 있으므로, command 단위로 설명을 적어주어야 한다.
- 발견한 유스케이스 단위로 테스트케이스 클래스를 작성한다. 
	- command 단위로 테스트 코드를 작성한다. command는 usecase의 메소드가 된다. 
	- cqrs를 적용하여 command(create, update, delete)와 query(read)객체를 구분한다. 
	- usecase 구현체는 "agent"service로 명명하여 구현한다. (기존의 service)
## output
### 도메인 모델
- 모델에는 풍부한 모델과 빈약한 모델이 존재한다. 인사이트를 통한 도메인 경계는 최초에 빈약한 모델을 갖는다. 도메인 경계내의 유스케이스들을 하나씩 구현해 나가다보면 풍부한 모델로 발전하게 된다.
- 도메인 모델은 [[마이크로서비스 아키텍처|MSA]] 로 아키텍처가 전환될 때 단일 마이크로서비스가 될 수 있어야 한다. 
### 테스트 코드
- 하나의 유스케이스는 하나의 테스트(클래스) 코드로 표현되어야 한다. 
- 인프라(api, persistance, external system)를 이용하는 부분은 java의 interface로 표현하고, 이를 “Port"라고 정의한다.
- 테스트 케이스는 블랙->화이트 순으로 고려하여 설계한다.
	- 상세 내용은  [[소프트웨어 테스팅]] 참고
	- 개발 공정상 전체 아키텍처의 테스트 코드들은 [[소프트웨어 테스팅#^2923ee|하향식]]으로 작성되게 된다.
### Port 
- port에는 두 종류가 존재한다. 도메인을 중심으로 in-port와 out-port로 구분한다. 이 두 종류의 port가 다음 공정인 [[인프라 테스트]] 공정에 구현해야 할 (소리치는) 부분이다.
- in-port
	- 도메인 모델이 수신하는 데이터 혹은 바이트에 대한 inteface 정의이다.
	- interface의 method 파라미터는 조회성인 경우 query, 그 외에는 command로 표현한다. 
	- in-port에 대한 구현체를 “Agent" 라고 명명하고 이 service는 in-port와 out-port를 연결하는 중립 구현체의 역할을 수행한다. ^7bc277
	- Spring과 같은 컨테이너 프레임워크를 사용하는 경우 @Service로 표현되는 Bean instance이다. 
- out-port ^e62cc9
	- 주로 persistence(database) 가 수행해야할 interface 정의이다.
	- smtp, messaging 등과 같은 인프라 환경에 대한 interface 정이다.
	- out-port를 구현하는 adaptor를 작성하여 이용해야할 외부 인프라를 유연하게 연결할 수 있다.
## 구현사례
- [회원가입 usecase 설계구현]