johanhaleby/domain-storytelling

도메인 스토리텔링

도메인 스토리는 비즈니스 프로세스를 문장으로 표현한 그림입니다: 액터가 작업 객체를 사용하여 무언가를 하며, 때로는 다른 액터와 협력합니다. 화살표의 숫자는 순서를 나타냅니다. 다른 어떤 것도 순서를 나타내지 않습니다.

이 스킬은 스토리를 모델링한 다음 렌더링합니다. 중요하지 않은 것을 모델링하기 전에 references/notation.md와 references/spec.md를 한 번의 호출로 읽으십시오. 명세 파일에는 모든 아이콘 이름이 나열되어 있습니다.

단계

1. 스토리 모델링. 초안이 기본입니다: 사용자가 설명한 것에서 일반적인 사례를 모델링하고, 아이콘을 선택하고, 렌더링한 후, 어떤 가정을 했는지 말하십시오. 모델을 장식하는 것이 아니라 변경할 선택에 대해서만 질문하십시오.
2. 문장을 한 번 읽어주고 그중 어떤 것이 선택 사항이거나 때때로 다르게 발생하는지 질문하십시오. 그것들은 주석이 됩니다. 이것은 건너뛰기 가장 쉬운 부분이며, 건너뛰면 가장 많은 비용이 발생합니다. 표기법에는 분기가 없기 때문입니다. 때때로만 발생하는 단계는 주석을 달거나 행복한 경로에 조용히 합류합니다.
3. 대신 워크숍을 진행하십시오 사용자가 워크숍을 요청하거나(/domain-storytelling workshop, "워크숍 진행", "이것에 대해 인터뷰해 주세요"), 계획이 아무도 기록하지 않은 프로세스에 달려 있을 때. 지금 references/workshop.md를 읽으십시오. 인터뷰와 그림을 동시에 하지 마십시오.
4. 명세를 작성하고 아래 렌더링에서 설명하는 대로 렌더링하십시오.
5. 경고에 따라 행동하십시오. 생성기가 stderr에 무엇이든 쓸 때, 지금 references/warnings.md를 읽으십시오. 생성기는 해당 파일의 이름을 지정하는 줄로 끝나므로, 읽기를 건너뛰면 출력에 표시됩니다.
6. 그림을 검사하십시오 렌더가 작성한 미리보기 PNG를 읽고, 작성된 모든 파일의 이름을 지정하십시오. 렌더는 경고가 없고 그림이 깔끔하게 추적될 때 완료됩니다.

양보할 수 없는 규칙

이 규칙들은 방법론에서 비롯된 것이며, 이를 위반하면 도메인 스토리처럼 보이지만 실제로는 그렇지 않은 것이 생성됩니다.

• 모든 액터는 정확히 한 번 나타납니다. 액터당 하나의 도형, 그것이 포함된 문장의 수와 관계없습니다.
• 다른 역할을 하는 두 사람은 도메인이 같은 용어로 부르더라도 두 명의 액터입니다. 위의 규칙은 한 액터를 한 번 그리는 것에 관한 것이지, 한 단어를 한 번 그리는 것에 관한 것이 아닙니다. 같은 명사의 두 언급을 병합하기 전에, 한 사람이 두 단계를 모두 수행할 수 있는지 질문하십시오. 수행할 수 없는 경우, 별도의 액터이며, 각각의 역할을 나타내는 별도의 도형과 이름을 가집니다. 순서 번호가 이것을 단순히 모호하게 만드는 것이 아니라 잘못되게 만드는 이유는, 순서 번호가 문장 5를 수행하는 액터가 문장 2를 수행한 액터와 동일하다고 주장하기 때문입니다. 분류 대기열에 합류하고, 주차 공간을 비우고, 그런 다음 비워진 공간을 차지하는 단일 운전자는, 운전자가 주차 공간을 포기하고 다시 제안받았다고 말하는데, 떠나는 소유자와 대기자는 직함을 공유하는 두 가지 역할입니다. 다른 사람이 그 단계를 수행할 수 있다고 명명하는 주석 ("관리자가 대신 주차 공간을 비울 수 있습니다")은 그 단계의 액터가 결정되지 않았음을 나타냅니다.
• 모든 활동은 자체 작업 객체를 그립니다. 세 문장에서 동일한 순서는 세 개의 도형입니다. 이것은 중복이 아니라, 표기법이 사물의 이동을 보여주는 방식입니다.
• 조건문, 분기 또는 루프가 없습니다. 게이트웨이, 다이아몬드, 점선 "if"가 없습니다. 중요한 대안은 별도의 스토리로 모델링하십시오. 작은 변형은 주석으로 유지하십시오.
• 문장은 액터로 시작하며 순서 번호는 첫 번째 화살표에 붙습니다. 두 번째 액터로 가는 화살표에는 숫자가 아닌 전치사가 붙습니다.
• 동시에 발생하는 문장은 하나의 번호를 공유하며, 여러 문장이 공유할 수 있습니다. 명세에서 n 값을 여러 문장에 반복하십시오. 이것이 표기법이 "동시에"를 말하는 유일한 방법입니다. 분기와 조인이 없기 때문에, 한 단계가 다른 단계를 기다리지 않을 때마다 이것을 사용하십시오. 한 단계가 진정으로 다른 단계를 따를 때는 번호를 분리하십시오. 공유된 번호는 "이 두 개는 관련이 있다"는 이상을 주장하기 때문입니다.
• 도메인 자체의 용어를 사용하십시오. 화살표의 동사는 도메인 전문가가 말한 단어입니다. "처리" 또는 "처리하다"를 쓰고 있다면, 아직 단계를 이해하지 못한 것이므로 질문하십시오. 코드에서 가져온 스토리에서 도메인의 단어는 사람이 트리거하는 동작, 즉 버튼, 엔드포인트 또는 명령의 이름이므로, cancel-reservation 엔드포인트는 "예약을 취소합니다"를 만듭니다. 각 동사는 하나의 동작을 명명하며, 하나의 스토리에서 두 개의 다른 동작은 두 개의 다른 동사를 얻습니다. 액터를 명명하기 전에 엔드포인트를 호출하는 화면을 따르고, 해당 화면의 사용자에 따라 액터를 명명하십시오. 백오피스 사용자와 관리자 편집기의 전문가 서비스는 다른 역할이며 다른 작업을 수행할 수 있기 때문입니다. 인접한 동작이 유사한 효과를 가질 때, 주차 공간의 예약을 취소하는 것과 대기열에서 대기자를 제거하는 것은, 메모는 화면과 버튼, 그리고 그것이 아닌 인접 동작을 명명합니다.
• 작업 객체는 도메인이 이미 말하는 하나의 명사입니다. "인보이스", "주차 공간 클레임". 이름에 and가 있으면 두 개임을 나타내며, 수정 방법은 활동이 실제로 이동시키는 것을 선택하거나 번호를 공유하는 두 개의 문장을 작성하는 것입니다. 길이는 결함이 아니라 증상이므로, 복합 이름을 줄여서 맞추는 것은 그것을 숨길 뿐입니다.
• 범위를 명확히 말하십시오. 세분성, 시점, 도메인 순수성. 이 범위 없이 스토리는 무엇을 주장하는지에 대해 모호합니다. 범위는 그림이 아닌 명세와 Egon 설명에 포함됩니다. 이 세 가지 용어는 방법론이 모델러와 대화하는 방식이며, 이미지의 독자는 이를 해독할 수 없습니다.

변경 사항이 적용되는 위치 표시

스토리의 요점이 변경이 프로세스에 미치는 영향일 때, 변경이 적용된 문장을 "changed": true로 표시하고 설명에 그렇게 명시하십시오. 변경 사항이 표시된 한 장의 그림이 일반적으로 독자가 눈으로 비교해야 하는 두 장의 그림보다 낫습니다. 단계가 액터 간에 이동하거나 사라진 경우, 즉 프로세스의 형태가 변경된 경우에는 AS-IS 및 TO-BE 스토리를 대신 그리고, 단계가 그대로 있고 내용만 변경된 경우에는 그렇지 않습니다.

변경이 누군가가 무언가(제안, 우선 순위 또는 차례)를 받을지 결정할 때, 대비를 그리십시오: 손해를 보는 사람과 이익을 얻는 사람, 같은 역할의 두 액터로, 위치에 따라 이름을 지정하십시오("첫 번째 대기자", "두 번째 대기자"). 누가 그것을 얻었는지 명명하는 문장으로 끝내십시오. 그 역할에 단 하나의 액터가 있는 경우, 누군가를 건너뛰는 규칙은 아무것도 하지 않는 규칙과 정확히 동일하게 그려집니다.

사람이 아닌 코드에서 가져온 스토리는 해당 코드를 읽은 것입니다. 그림 옆에 그렇게 명시하여, 독자가 작업을 수행하는 사람과 확인되지 않았음을 알 수 있도록 하십시오. 변경된 문장을 그리기 전에, 새로운 동작이 적용되는 시기를 결정하는 가드(필요한 상태와 실행하는 이벤트)를 읽으십시오. 해당 이벤트를 변경 전의 문장으로 그리고, 스토리 전체가 유지하는 상태(예: "떠나는 운전자가 아직 주차되어 있습니다")를 설명에 넣으십시오. "다음에 대기열이 요청될 때"와 같은 메모는 액터를 명명하지 않으며, 트리거가 발견되지 않았음을 나타냅니다.

스토리 개수

• 중요한 대안당 하나의 스토리. 행복한 경로가 먼저입니다.
• AS-IS와 TO-BE는 항상 별도의 스토리이며, 하나의 그림이 아닙니다.
• 프로세스가 큰 경우, 대략적인 개요와 중요한 단계에 대한 세부 스토리 하나.
• 다른 모든 조건이 동일할 때 약 15문장에서 분할하십시오. 넓고 복잡한 그림은 방법론이 스토리가 너무 크다고 알려주는 것입니다.

집합이 집합으로 읽히도록 이름을 지정하십시오: 환불 - AS-IS, 환불 - TO-BE.

렌더링

JSON으로 명세를 작성한 다음, 이 SKILL.md가 있는 디렉토리에서 생성기를 실행하십시오:

python3 scripts/story2egn.py path/to/story.json --preview <scratch dir>

표준 라이브러리만 사용합니다. 명세 옆에 두 개의 파일을 쓰거나 --out-dir에 쓰고, --preview는 자체 디렉토리에 <제목>.png를 추가하므로, 한 번의 호출로 스토리를 렌더링하고 그림을 다시 읽을 수 있습니다. --preview를 스크래치 또는 임시 디렉토리로 지정하고, 제공되는 파일과는 다른 곳에 두십시오. PNG는 rsvg-convert, cairosvg 또는 inkscape가 설치된 경우 이를 사용하고, 그렇지 않으면 macOS Quick Look을 사용합니다. --help는 다른 형식과 --date를 나열합니다.

• <제목>.egn.svg는 그림과 편집 가능한 모델이 하나의 파일에 담겨 있습니다. 모든 SVG 뷰어에서 열리며 https://egon.io에서 가져올 수 있습니다. Egon은 파일 이름에서 스토리 제목을 읽으므로, 명세의 제목이 파일 이름을 결정합니다.
• <제목>.board.svg는 페이지용 동일한 그림입니다. 모든 액터, 작업 객체, 활동 및 메모는 해당 단계에 태그된 그룹에 있으며, 자체 다크 모드를 지원합니다. scripts/story-board.js는 하나의 단계를 어둡게 하거나, 테두리를 표시하거나, 자를 수 있습니다. egon.io에서 손으로 그린 보드에는 태그가 없으므로 일반 이미지로 유지됩니다.

항상 사용자에게 작성된 경로를 알리십시오. 호스트가 이미지를 표시할 수 있으면 그림을 인라인으로 보여주고, 그렇지 않으면 경로가 전달물입니다. 파일 이름을 명명하지 않고 스토리가 생성되었다고 말하지 마십시오.

스토리 다시 읽기

.egn, .egn.svg 및 레거시 .dst 파일은 형제 스킬 egn-to-text로 읽습니다. 여기서 구문 분석하지 말고 해당 스킬을 사용하십시오.