### 목차
- [(서문) 개발공정](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
테스트를 별도의 공정으로 분리하는 개발 방법론들이 대대수다. 공정명에 '테스트'를 포함시킴으로, 코드와 인프라(주로 데이터베이스)에 대한 단위 및 통합 테스트를 수행하도록 상기할 목적으로 공정명을 정하였다. 이 공정은 [[유스케이스 구현]]공정에서 소리치고 있는 [[유스케이스 구현#Port|Port]]에 대한 구현체를 개발하는 공정이면서, 애플리케이션 아키텍처와 Context를 결정하는 공정을 포함하고 있다.
## tool
- [[유스케이스 구현#tool]] 항목을 포함
- Spring : framework, boot, cloud, security 등 다양한 서브 프로젝트들로 구성되어있으며, 이들 조합만으로 빠른 시간내에 엔터프라이즈급 제품을 생산해낼 수 있다.
- Docker : 리눅스의 container를 이용하여 가상 환경을 제공해준다. 개발 환경과 운영 환경을 최대한 동일하게 유지 시켜주는 장점이 있다.
- Git : 소스 버전을 관리할 때 사용한다. 분산환경에서 소스 통합에 강력하다.
- Database : 일반적으로 Persistance, Repository 등으로 해석되는 인프라 솔루션들을 총칭한다. Oracle, MySql, PostreSQL 등의 관계형 데이터베이스과 MongoDB로 대표되는 NoSQL 군으로 분류된다.
- 기타 : SMTP, Messaging Servier 등
## activity
- 애플리케이션 아키텍처
- Auth : 엔터프라이즈급 애플리케이션은 기본적으로 인증/인가 기능을 제공하거나 이용할 수 있는 수단을 제공해야한다. Spring에서는 Spring Security를 통해 다양한 방법을 제공하고 있다.
- Context : 애플리케이션의 코드를 실행하기 위한 여러 환경(또는 상황)에 대한 설정을 제공해야한다. DB접속정보 등
- in-port 파라미터 공급
- in-port 구현체는 [[유스케이스 구현#^7bc277|유스케이스 구현 공정에서 제공]]하고 있으므로 해당 agent에 파라미터를 정확하게 공급하는 것을 목적으로한다.
- Spring Boot에서는 @Controller 로 표현되는 Bean instance이다.
- out-port Adaptor 구현
- [[유스케이스 구현#^e62cc9|out-port]]에 대한 구현 클래스를 바로 작성하지 않고 Adaptor 클래스를 중간에 유지하는 이유는 애플리케이션 간 결합도를 낮추기 위함이다.
- 인프라 영역은 데이터베이스 등과 같은 외부 솔루션과의 연계가 주 목적이므로 외부 솔루션이 변경되었을 때를 항상 대비하여야 한다.
## output
### Api
- 사용자는 UI(User Interface)를 통해 애플리케이션을 사용한다. UI가 애플리케이션을 이용하려면 프로그래밍적으로 접근해야 할 것이다. 이 기능을 제공하는 것을 API(Application Programming Interface)라고 부른다.
- 웹 애플리케이션의 경우 대부분 Rest API라는 방식을 이용하며, 주로 JSON 형태로 데이터를 교환한다.
### Mapper
- 모듈 또는 클래스간 의존성을 줄이기 위해 레이어 아키텍처, 헥사고날 아키텍처 등과 같은 검증된 아키텍처를 이용하게 된다. 이 아키텍처들은 "경계"를 가지고 있으므로 그 경계를 지날때는 전달할 객체(파라미터)를 변환하여 전달해주게 된다. 이러한 변환 객체를 "Mapper"라고 한다.
- Mapper에 대한 별도 테스트 코드는 작성하지 않는다.
- [VO 그거 꼭 변환해야하나](https://youtu.be/UgaqRs-qTHo?si=vUT-7RXSNnjLrJcV)
### Adaptor
- 유스케이스의 out-port와 인프라간의 Adaptor이다. Adaptor는 주로 데이터베이스가 되는 경우가 대부분이지만 SMTP, Messaging 등이 될 수도 있다.
### Context
- 애플리케이션 실행시 사용할 환경 정보이다. 애플리케이션 구현시 실행 arguments로 제공하는 것이 보안상 가장 안전한 방법이지만,
- 보안상 문제가 되지 않는 설정 정보라면 Spring에서는 주로 application.yml 파일에 설정하게 된다.
- profile을 이용하여 배포환경 별로 구분할 수 도 있다.
### 단위 테스트 코드
- Api, Adaptor에 대한 단위 테스트 코드를 작성하게 된다. 실제로는 Mock 객체를 잘 활용해야하는 통합테스트 수준의 테스트 코드이므로 예상치 못하게 작성하는데 시간이 오래 걸릴 수도 있다
- 데이터베이스 같은 경우 docker container를 활용한 테스트를 수행 할 수 있다.
- api, infra에 대한 단위 테스트 : 화이트 -> 블랙 순으로 고려햐여 (유스케이스는 역순)
- 상세 내용은 [[소프트웨어 테스팅]] 참고
## 구현사례
- [회원가입 api 구축]
- [회원가입 infra 구축]
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
Inlay Hint > Parameter names java.inlayHints.parameterNames.enabled: literals java.inlayHints.parameterTypes.enabled java.inlayHints.variableTypes.enabled editor.inlayHints.enabled: offUnlessPressed Code lens editor.codeLens: true editor.codeLensFontSize java.referencesCodeLens.enabled java.implementationCodeLens: all ligature 폰트 설정 editor.fontFamily: 'D2Coding ligature’ "editor.fontLigatures": true, 편집기 확대 축소 단축키 설정 zoom 으로 검색 Google Style Formatter 설정 java.format.settings.url https://raw.githubusercontent.com/google/styleguide/gh-pages/eclipse-java-google-style.xml JDK 설정 java.configuration.detectJdksAtStart Language Server JAVA_HOME 설정 java.jdt.ls.java.home Gradle JAVA_HOME 설정 java.import.gradle.java.home Installed JDK 설정 java.configuration.runtimes Static 클래스, 메서드 import java.completion.favoriteStaticMembers "org.springframework.test.web.client.match.MockRestRequestMatchers. ", "...
# 5-Step Architecture Spec 이 문서는 헥사고날 아키텍처를 실무적으로 변형하고, DDD의 전략적 설계를 극대화한 5-Step Architecture의 표준 공정을 정의한다. 샘플 리파지토리 : https://github.com/ohhoonim/smart-factory/tree/main/back/factory-api-module ### Core Philosophy > "Service는 배달부(Messenger)일 뿐, 뇌(Brain)는 **Model**에, 법(Law)은 **Policy**에 둔다." > --- ## The 5-Step Standard Process ### Step 1: 도메인 자아 확립 (Domain Model Discovery) 비즈니스의 핵심 상태와 행위를 관리하는 Aggregate Root(AR)를 정의한다. - **원칙**: 데이터 필드가 아닌 '상태 변화의 규칙'과 '생애주기'에 집중한다. - **핵심**: AR 내부에서만 상태 변경이 가능하도록 캡슐화하며, 외부로부터의 직접적인 필드 수정을 금지한다. ### Step 2: 법전 정의 (Policy Abstraction) 비즈니스 제약 조건 중 변하기 쉬운 규칙(보안, 한도, 계산 로직)을 인터페이스로 추상화한다. - **원칙**: 도메인 모델이 프레임워크(Spring)나 환경 설정에 오염되지 않도록 보호한다. - **효과**: 정책의 변경이 모델이나 서비스의 코드 수정을 유발하지 않도록 결합도를 낮춘다. ### Step 3: 도구 제작 (Activity Implementation) 도메인이 외부 세계와 소통하기 위한 구체적인 기술(DB, Storage, 외부 API)을 구현한다. - **원칙**: 헥사고날의 **Output Adapter** 역할을 수행하며, 기술적 복잡성을 이 계층에 가둔다. - **명칭**: `QueryActivity`(조회), `CommandActivity`(...
댓글
댓글 쓰기