일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |
Tags
- 대칭 키 알고리즘
- ruby
- 오블완
- 코틀린
- Mutation testing
- 직접 코드로 구현
- AES-GCM
- Test
- standard input
- resize image with go
- 객체지향
- https 서버 구현
- JPA
- InnoDB
- Pitest
- image resizer with go
- standard output
- https 실습
- kotlin
- cli 만들기
- https implement
- IntelliJ
- resizer 구현
- go https 구현
- HTTPS
- 돌연변이 테스팅
- 자바
- https go
- MySQL
- Java
Archives
- Today
- Total
Rlog
우아한 러닝 1주차 본문
728x90
이벤트 스토밍
- 도메인을 빠르게 익히기 위해 하는 과정
- 도메인 지식의 상향 평준화가 목표, 서로 배우는 것이 중요함.
- 이벤트 스토밍은 기록 및 관리하려고 하면 안됨. 그냥 워크샵에서 끝내는게 좋음. -> 유지보수 하려고 하는 대상으로 만들지 않아야 함.
- 준비물
- 큰 회의실, 종이, 포스트잇 마커펜
- 실제 문제 해결에 관련된 모든 사람(질문이 있는 사람) -> 해당 도메인 전문가 느낌.
- 교육이나 회의를 리드하는 사람(진행자)
- 진행방법
- 벽에 커다란 종이를 붙여 놓고 포스트잇(도메인 이벤트 중심)을 붙여 나간다
- 도메인 이벤트 설명은 혼란스러운 탐험의 도메인 이벤트 설명을 참조.
- 비즈니스 프로세스를 이해하는 데에 초점을 맞춘다.
- 모든 사람의 생각을 허용하고 존중한다.
- 벽에 커다란 종이를 붙여 놓고 포스트잇(도메인 이벤트 중심)을 붙여 나간다
혼란스러운 탐험(1단계)
- 각자 알고 있는 도메인 이벤트를 작성하도록 요청한다. (예를 들면, “전자계약서가 생성됨” 과 같은)
- 작성한 이벤트는 볼 수 있지만, 토론을 시작하지 말고 자신이 옳다고 생각하는 방식으로 기록한다. (일단, 남이 적은게 틀렸던 말던 신경쓰지 말고 생각대로 막 적기)
- 중복되던 말던 일단 자신이 떠오르는 이벤트를 마구잡이로 적는 단계
- 도메인 이벤트 - 주황색
- 도메인 전문가가 관심이 있는 어떤 사건
- 이벤트 이름은 과거에 일어났던 일이기 때문에 과거시제 이용
- 이벤트가 발생했다는것은 상태가 변경되었다는 것을 의미한다.
- 타임라인 적용
- 시간별로 왼쪽 -> 오른쪽으로 이벤트를 적는다.
- 위, 아래와 같이 수직적인 것은 같은 시간을 의미
- 핫스팟 (빨간색 포스트잇)
- 타임라인을 적으면서 발생한 갈등을 시각화하고 캡쳐하는데 사용
- 당장 5분 이상 토론하지 않는다. (나중에 티켓으로 등록하여 처리)
- 액터와 시스템 (분홍색 포스트잇)
- 단순한 “사용자” / 고객 보다 구체적인 페르소나를 설정한다.
- 예를 들면 “업주” -> “XX 상품에 가입한 업주”
- 외부 시스템(AWS 등등) 부터 일부 레거시 및 마이크로서비스에 이르기까지 책임을 전가할 수 있는 모든 것
- 단순한 “사용자” / 고객 보다 구체적인 페르소나를 설정한다.
타임라인 적용(2단계)
- 혼란스럽게 나열된 도메인 이벤트 들을 시간 타임라인 순으로 정렬한다.
- 잘 모르겠는 도메인 이벤트에 자주색 포스트잇(Hotspot) 으로 질문을 달아 둔다.
커맨드 / 액션
- ~ 무언가 하는것 메소드
- 액터의 행위
리드 모델 또는 정보
- 액터가 결정을 내리는데 필요한 정보
- 액터가 리드모델을 읽고 명령(Command)을 내림
- 주문, 상품 등등
정책
- 주로 ‘~할 때마다’ 라는 단어로 시작한다.
- ‘~ 정책(Policy)에 따르면 ~을 한다(Command)’
- 강사가 강의를 생성하면 강의 정책에 따라 미션이 생성된다.
애그리게잇(Aggregate) 또는 비즈니스 규칙(동의어)
- 시스템이 기대하는 책임을 수행하며 일관성을 유지하는 단위
- 수강생 수는 XX 명을 넘을 수 없다.
- 일관성은 항상 참이어야 하는 속성을 유지함으로써 달성된다.
- 동시성으로 인해 넘을 수도 있음. 하지만 비개발자는 이유를 알 수 없어서 이벤트 스토밍과정에서 이런 이유를 설명해주고 이를 불변으로 설정해야 함.
애그리게잇과 정책 구별법
- 특정 조건으로 유효성 검사를 해야할경우 어그리게잇임.
- 특정 정책에 의해 Command 가 실행되어야 하는가?
빅픽쳐(대략적으로 진행되는 순서)
위의 순서대로 보통은 진행된다고 한다.
바운디드 컨텍스트(Bounded Context)
- 같은 용어라도 의미가 다르고 같은 대상이라도 지칭하는 용어가 다른 경우가 있다.
- 명백한 언어 불일치는 종종 동일한 프로세스내에서 여러개의 바운디드 컨텍스트를 나타내는 지표이다. -> 누군가는 상품을 “A” 라고 하고 누군가는 “B” 라고 할 경우 경계를 긋고, 여기서는 상품을 “A” 라고 하고 여기서는 “B” 라고 하자 라고 하는 것.
- 예를 들면 특정팀은 주문이라는 것을 포괄적으로 말하지만, 특정 팀에서는 포장주문 / XX 주문등으로 나뉨. 이 경우 경계를 광고가 아닌 경계를 구분지어 포장주문 / XX 주문으로 나누어 말함. 이 구분 지은 경계(바운디드 컨텍스트) 에 따라서 팀이 분리되거나 도메인 모델이 분리됨.
#workshop-woowahan #week1
'일일회고' 카테고리의 다른 글
HAR File 로 HTTP Request 추적하기 (0) | 2022.06.10 |
---|---|
2021 늦은 회고 (2) | 2022.01.17 |
2021-11-09 (0) | 2021.11.09 |