### 목차
- [(서문) 개발공정](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
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`(...
댓글
댓글 쓰기