RDRA와 EventStroming의 조합 가능성

이 기사는 DDD-Community-Jp Advent Calendar 2020의 10일째다.

■ 시작

Discord의 커뮤니티 DDD-Commusiy-Jp(#dddcj, #ModelingKai)에서
모형을 만들어라!
==>모델링이 완성되었으니 설치해 보세요!
==>좀 이상한데!?디자인 프레임을 사용하세요!
==>좀 이상한데!?디자인 프레임을 조합해 보세요!
이동에서 반복적으로 설계, 설치한 결과
RDRA와 EventStorming(디자인 수준)을 조합해보면 잘 나오지 않나요?이런 가설은 시행의 범주지만 실증되고 있다.
이번에 나는 이런 의식의 언어화에 도전하고 싶다.
※ 이 기사는 RDRA와 이벤트스토밍에 관한 자세한 내용은 생략했습니다.
EventStorming에 대해서는 이 보도를 참조하십시오.

■ RDRA는 분석 요청 방법이고 이벤트스트로밍은 이벤트 분석 방법

RDRA와 EventStorming은 목적과 시각이 완전히 다르다.
대충 비교해 보면 다음과 같은 인상이 있을 것이다.
잘못
RDRA
EventStorming(설계 수준)
중요시
정보의 연관성
활동 연관
방어 범위
요구에서 용례로
용례 전후~상세한 상황
시선
프로젝트 전체를 내려다보다
상세한 사건을 주시하고 있다
RDRA는 더 넓은 범위를 볼 수 있는 프레임워크입니다.
EventStorming은 더 세부적인 범위 내에서 강력한 프레임워크입니다.
수비 범위가 중복되지 않고 둘 다 대체로 용례의 전후부터/끝부터 상성이 좋다고 느낀다.

■ RDRA와 EventStorming(디자인 수준)이 서로 보완되는'무엇'

위 표에서도 알 수 있듯이 RDRA는 부감이고, 이벤트스토밍은 상세한 내용이다.
RDRA는 분석이 필요한 프레임워크이기 때문에 전체 프로젝트의 부감에 적합하다
실크로 직접 연락하기는 좀 어려워요.
한편, EventStorming은 이벤트(이벤트)에 초점을 맞춘 프레임워크입니다.
활동이나 집합이라기보다는 코드와 밀접한 관련이 있는 분석 결과라고 할 수 있다
시스템 전체의 상황을 파악하는 능력이 부족하다.
그림을 만들면 이런 느낌이에요.

예를 들어 RDRA와 이벤트스토밍은 좋은 느낌을 준다.
RDRA의 부족한 디테일과 이벤트스토밍이 부족한 추상적인 보완은 좋은 보완 관계가 있지 않습니까?

■RDRA와 EventStorming을 실제로 조합해보기

RDRA를 2-3바퀴 돌려 전체 이미지를 잡은 후 이벤트스토밍으로 더 자세한 내용을 설명한다.
그런 다음 EventStorming에서 받은 이벤트, 요약, 고려 사항을 RDRA의 그림으로 복원합니다.
RDRA의 그림을 수정하면서 콘셉트 모델을 정리하는 등 그곳에서 나타난 주의사항을 이벤트스토밍에 반영했다.
RDRA→EventStorming→RDRA→EventStorming처럼 서로 수정을 반복한다.
RDRA에 나오는 언어와 EventStorming 언어가 연결되어 있음
필요한 조건부터 실제 발생하는 활동, 그리고 이 활동과 관련된 총결산은 모두 일종의 연계이다.
RDRA는 정보 관련을 의식하는 프레임워크이기 때문이다
나는 다른 틀과의 연결성이 좋은 특징을 발휘했다고 생각한다.
　
RDRA와 EventStorming을 조합한 결과 추상적인 요구와 요건에서 실제 포장까지의 길을 개척했다.
이후에는 실장만 추진했다.

■ 실상과 모형의 불길한'냄새'

모델링 회의에서 우리는 실제로 모델에서 실현을 시도하고 있다.
처음으로 모델링 프레임워크를 사용하지 않아 모델링에 실패했습니다.
두 번째는 반성을 살려 RDRA와 이벤트스토밍으로 모형을 만들었습니다.
틀의 실시에 따라 설치가 순조롭게 진행되지 않는 현상이 나타났다.
생각나는 이유가 몇 가지 있어요.
그중에서 가장 큰 영향을 미치는 것은 바로'다들 잘못 이해했다'는 것이다.
네, 실장을 추진하다 보니 어느새 서로 하는 말과 단어의 전제가 빗나가기 시작했어요.
"어? 아닌가?""아니야, 아니야, 그렇지?"이런 대화가 시작됐다.
점점 대화에서 서로 다른 인식으로 인해 위화감을 나타내기 시작했다.
　
실복 중이든 아니든 불협화음이 생길수록 "다들 모델에 대한 인식이 어긋난다"며 모델에 안 좋은 점이 있을 수 있다.
예를 들어 모형의 구조가 잘못되고 모형의 이름이 정확하지 않다는 등이다.
커뮤니케이션의 불일치를 계기로 이른바'코드의 맛'과 마찬가지로'모델의 맛'이 느껴졌다.

모델로 돌아왔을 때 말이다.

■ 모델에게 돌아와 불길한'냄새'에 대처

냄새를 바탕으로 모델을 예쁘게 만들어 봅시다.
이 일대는 확실히 RDRA와 Event Storming이 잘하는 곳이다.
어느 틀이든지 모델을 통해 추상적이고 구체적인 순환을 통해 정밀도를 높인다.
게다가 코드에서 얻은 피드백은 아래 그림과 같이 모든 연결을 설치할 것을 요구합니다.
코드에서 느끼는 냄새가 절구가 되어 모형의 맛을 알아차리면 모형을 수정할 수 있다.

그래서 모델의 언어의 정밀도가 높아지고 뜻이 통일되며 코드가 세련되었다.
요구부터 실행에 이르기까지 모두 덮어쓸 수 있는 조합이 아닌가.

■향후 전망

이번 시험은 도대체 #dddcj의 모범회라는 초등학교 학습회의 경험일 뿐이다.
제품 코드에서도 같은 생각을 잘 활용할 수 있는지 앞으로 도전할 기회를 보고 싶습니다.