### 목차
- [(서문) 개발공정](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 설계구현]
Session 대신 JWT를 사용하는 이유 실 서버는 하나의 인스턴트로만 동작하지 않는다. 서버의 고가용성(high availabliity, HA)을 확보하기 위해 두 개 이상의 병렬서버로 운영하게 된다. 서버가 병렬로 운영되는 상황에서 세션을 사용하면 각 서버간의 세션을 동기화하는 문제가 발생한다. 이를 해결하기 위해 공유 데이터베이스를 이용한 세션공유 기법들을 사용하기도 한다. 서버가 많아지면 세션동기는 더 어렵다. JWT를 사용하면 세션사용으로 인한 서버 자체에 부담도 줄이면서 공유 세션에 대한 관리가 한층 수월하다. 스프링 시큐리티 - SecurityConfig.java session을 사용하지 않도록 설정 jwtAuthFilter 추가 httpBasic 제거 - JwtAuthenticationFilter.java config.filter 패키지에 파일 추가 jwt dependency 추가 (3개). gradle refresh하는 거 까먹지 말기 config.service 패키지에 [JwtService.java](http://JwtService.java) 추가 jwtService와 UserDetailService final field 추가. @RequiredArgsConstructor 까먹지 말기 - config.service.JwtService 소스 참조해서 파일 작성 - controller, service 수정 User 를 리턴하면 pwd가 그대로 노출되므로 AuthResponse와 AuthRequest로 교체 Github https://github.com/ohhoonim/factory.git 유튜브 영상 스프링부트 - 보안 JWT JWT - refresh 토큰과 logout
``` [!NOTE] Winddows와 Macos macos를 기준으로 설명하고 있으나, 거의 대부분 macos의 `Cmd`키를 `Ctrl`키로 변경하면 windows에서도 그대로 사용할 수 있음 ``` # VSCode 단축키 - `Cmd + p` : 파일 오픈을 위한 palette - `Cmd + shift + p` : 명령어 실행을 위한 palette. `Cmd + p` 한 다음 '>'를 입력해도 됨 - `Cmd + shift + o` : 현재파일에서 심볼 찾기 (field, method, function 등). `Cmd + p`한 다음 '@'를 입력해도 됨 - `Cmd + Opt + ` : 열려있는 편집기 전환 - `Cmd + shift + e` : 편집기와 탐색기를 전환 함. (탐색기에서 vim 커서 이동 키도 동작한다는 것이 핵심) - `Cmd + Opt + ` : 열모드로 블럭 지정. (VIM단축키와 조합하면 최상임. 이건 글로 설명이 안됨) --- ``` [!NOTE] VSCode용 Vim 확장 - 여기서는 vscodevim 에서 제작한 Vim 확장을 설치하여 사용한다. Vim 단축키는 다를 바 없다. - `esc`키를 눌러 Normal모드 진입시 '한글' 입력상태인 경우 많이 불편하다. '한영'을 자동으로 변환해주는 여러 방법들을 써봤지만, 몇 일 지나면 풀려서 잘 동작 안한다. 그냥 Normal 모드 진입시 '한영'변환을 신경써서 잘 해주자. (시간낭비하지 마세요) - macos의 경우 `Cmd`키와 `Caps`키를 바꾸자. - Windows의 경우 `Ctrl`키와 `Caps`키를 바꾸자. (써보면안다. 얼마나 편한지) ``` ``` [!warning] - 표기된 모든 단축키는 `대소문자`를 구분합니다. (shift 입력하기 귀찮아서임) - `잘라내기`라고 표기한 것은 `붙여넣기`가 가능하다는 뜻입니다. - VIM 모드 전환은 직...
설치하기에 앞서 테스팅 이야기 ISO/IEC/IEEE 29119 에서는 소프트웨어 테스팅의 표준standard에 대해 정의하고 있습니다. 돈받고 파는 문서를 '표준'이라고 번역하기는 좀 껄끄러운데요. 'standard'는 비지니스를 안정적으로 수행할 수 있는 잘 정리된 '가이드' 정도가 올바른 번역이 아닐까 생각됩니다. 소프트웨어에 표준이 있다면 얼마나 좋겠습니까마는 no silver bullet 이라는 말도 있듯이 이건 그냥 iso에서 제시하는 가이드일 뿐이라는 것이 개인적인 의견입니다. 뭐 대단한거 한다고 시작하는데 말이 많군요. (^^;) 29119 part2에서는 테스트프로세스를 다루고 있구요. 이 중 test management process 항목이 있습니다. 어딜가나 비지니스가 끼어드니 management는 빠지는 곳이 없네요. 먹고살려면 어쩔수 없죠. 경영진을 설득하기 위한 부단한 연구라고 인정하는 수밖에. 출처 : http://softwaretestingstandard.org/part2.php 테스팅 서버를 구성하는 이유는 test management process 관점에서 'test monitoring & control'이 필요하기 때문입니다. (위 그림에서 가운데 노란색 박스) testlink 는 오픈소스로서 전 세계에서 가장 많이 사용되고 있는 툴이며 monitoring과 control을 위해 적절한 기능을 제공하고 있다고 판단됩니다. 맨티스는 testing completion 조건을 만족시키기 위한 테스팅 조직과 개발 조직간의 협업툴로서 이용될 수 있습니다. 개발조직에서는 맨티스와 같은 버그 리포트 툴을 사용하고 있으며 bugzilla, jira와 같은 다른 버그리포트 툴로 대체될 수 있습니다. 본 포스팅에서는 monitoring & control 을 수행하기 위한 테스팅 환경 구축이라고 보시...
댓글
댓글 쓰기