프로덕트 요구사항 설명을 입력하면 이벤트스토밍을 거쳐 가상의 토론을 한후 예제(ExampleMapping) 문서까지 만들어주는 DDD기법이 이용된 PRD AI 해석툴입니다. |
요즘 바이브코드가 PRD만 입력하면 뚝딱 생성하는 기법들이 많이 소개가 되고 있는것같으며 여기서는 PRD는 빈틈없는 완벽함이 아닌~ 프로덕트의 방향성에 대한 비즈니스 심오한 간결함을 담아야 한다는 관점에서
구현에 필요한 모든 내용을 기술할수 없다로 출발하여 PRD가 구현에 필요한 내용이 되기까지 여정의 문서를 만드는 절차를 DDD(+애자일)에서 소개되는 일부 기법들을 이용해 해석하는 AI툴을 생성해 보았습니다.
- PRD를 잘작성하는것이 이 주제의 핵심은 아니며~ PRD는 빈약할수 있다란 전제하에 출발하는 샘플입니다.
- 이전단계의 생성물은~ 다음단계 참고하여 개선하는 Flow를 가질수 있습니다. 3번째 단계에서는 가상의 전문가를 투입해 평가를 진행하고 또 다음 스텝으로 진행합니다.
- 최종단계에서는 우리가 사용할 용어(개발에서 바로 변수명으로 사용할수있는)를 정리한후 TASK를 만듭니다.
Event Storming
- 데이터 중심설계는 개발자만 참석이 가능하며 비즈니스전문가와 대화를 이어갈수 없는것이 이벤트 중심설계와는 차이점입니다.
- 그래서 이 방식 초반에 무엇을 해야될지 모르는 시점 비즈니스 전문가도 이해하는 이벤트만을 가지고 이야기를 합니다.
이벤트
- 게시물이 작성됨
- 게시물이 수정됨
- 게시물이 삭제됨
- 댓글이 작성됨
명령
- 게시물 작성하기
- 게시물 수정하기
- 게시물 삭제하기
- 댓글 작성하기
액터
정책/조건/제약사항
- 사용자는 자신이 작성한 게시물만 수정 및 삭제할 수 있다.
- 관리자는 모든 게시물을 관리할 수 있다.
애그리거트/바운디드 컨텍스트
가상 협업자 토론
- 기획의 문서 완벽함을 요구하는것은 마트에 들어섯는데 무엇을 살지 우리가 결정도 안했는데~ 카운터에서 구경하지말고 당신이 필요한것 모두 한꺼번에 주문하세요와 같은것입니다.
- 필요한것을 추가할수도 있고~ 필요하다 생각했는데 뺄수도 있기때문입니다.
Example Mapping
- 우리는 기획단계에서 이러한 예제를 짜는것을 시간낭비라 생각합니다. 나중에 개발자가 쏟아부어서 모든것을 해결하면 되니까요
- 하지만 이것을 우리가 무엇을 개발할지 모르는 단계 이야기하는것은 중요합니다. 그리고 이것이 단지 개발된 코드 자체의 유닛테스트란 개념이 아닌 우리가 설계한 서비스/비즈니스 로직에대한 테스트 케이스를 만드는것입니다.
- BDD란것이 꼭 개발코드를 완성하고 하는 활동이 아닌~ 기획의 비즈니스로직 정책에 모순이 없나? 코드를 구현하기전 하는활동으로 초기단계 하는것은 중요합니다.
유비쿼터스 언어 정의 (Ubiquitous Language)
작업 티켓 및 타임라인
작업 티켓 상세
여기서 소개되는 툴은 다음 오픈된 코드를 통해서 동일하게 작동시키거나 개선해 나갈수 있겠습니다.