도메인 스토리텔링을 이해·설계·코드·테스트로 잇는 활용법을 완독하며 정리했다.

01핵심 개요

• 『도메인 스토리텔링』 1부는 워크숍 준비를, 2부는 완성한 스토리를 현실 문제에 적용하는 방법을 다룬다고 설명했다.
• 자동차 리스 업체 알폰 사례는 넓은 범위 파악, 신용위험평가 세분화, 개선안과 신규 서비스 설계 순서로 진행됐다.
• 도로공사 계획 공공기관 사례에서는 워크숍 3회로 유스케이스 40개와 도메인 스토리 5개를 도출했다고 소개했다.
• 도메인 지식과 코드 사이에는 요구사항 단계가 필요하며, 도메인 스토리에서 유저 스토리와 기능 명세를 뽑는다고 설명했다.
• 작업 객체와 시나리오의 동사를 코드 모델과 메서드에 반영하면, 객체 설계와 E2E 수용 테스트 도출에 활용할 수 있다.

02핵심 주장 / 논점 구조

• 영상은 도메인 스토리텔링의 핵심을 먼저 업무를 파악하고, 이후 개선 프로세스와 시스템을 설계하는 흐름으로 정리했다.
• 도메인 스토리는 모두가 이해할 공통 기반이고, 요구사항·기능 명세는 시스템을 구현할 만큼 구체적인 중간 산출물이라고 구분했다.
• 발표자는 바이브 코딩에서는 도메인 스토리를 잘 설명하고 남기는 일이 중요하며, 상세 구현은 AI에 맡길 수 있다고 말했다.
• 도메인 전문가의 말에서 문제와 불편을 파악하되, 해결책 모델링까지 그대로 맡기면 안 된다는 책의 논점을 소개했다.

03알폰 자동차 리스 사례의 적용 순서

• 자동차 리스 업체 알폰 사례에서 개발자들은 먼저 넓은 범위의 스토리텔링으로 전체 리스 프로세스 이해도를 높였다.
• 전체 흐름을 본 뒤 복잡해 보인 신용위험평가에 집중해, 신용평가 전문가와 더 세분화된 스토리를 만들었다.
• 전문가가 기존 시스템의 버튼·화면 중심으로 설명할 때는 컴퓨터 없이 업무한다면 어떻게 할지 질문해 순수한 스토리로 유도했다.
• 기존 프로세스의 불편을 확인한 뒤 개선 프로세스 스토리를 그리고, 신규 업무 시스템을 추가한 서비스 스토리까지 작성했다.

04도메인 언어와 직접 대화의 중요성

• 9장은 도메인 스토리텔링이 업무 처리 과정과 소프트웨어 요구사항을 논의하기 위한 도메인 지식 구축에 도움을 준다고 설명했다.
• 도로공사 계획 공공기관 사례에서는 워크숍 3회 동안 유스케이스 40개와 도메인 스토리 5개를 도출했다고 소개됐다.
• 해당 사례에서 네 번째 워크숍부터 개발자들이 이해한 시스템 업무를 설명했고, 도메인 전문가들이 이에 동의했다고 전했다.
• 문서만으로는 프로세스 파악이 부족할 수 있으므로 대화로 먼저 이해하고 문서는 놓친 부분을 보완하는 수단으로 보라고 했다.
• PM·PO가 도메인 전문가와 개발자 사이의 번역가가 되기보다, 두 집단의 직접 소통을 지원하는 편이 낫다고 설명했다.

05바운디드 컨텍스트로 경계 찾기

• 10장은 하나의 서비스에서 다수의 도메인 스토리가 나올 때 이를 한꺼번에 이해하기보다 경계를 나누는 방법을 다룬다.
• 영상에서는 바운디드 컨텍스트를 넓은 범위의 도메인 스토리 단위로 묶어 보는 개념으로 설명했다.
• 개인 PT 트레이닝 효율화 시스템 예시에서 고객 등록 흐름은 회원 신규가입, 운동 흐름은 수업 진행이라는 별도 묶음으로 제시됐다.
• 서로 다른 바운디드 컨텍스트에서는 같은 용어도 다른 의미로 쓸 수 있으며, 각 경계 안에서 유비쿼터스 언어가 고유하면 된다고 했다.

06요구사항 도출과 도메인 전문가의 한계

• 11장은 도메인 지식에서 곧바로 코드로 가기 어렵기 때문에, 요구사항이라는 중간 단계를 거쳐야 한다고 설명했다.
• 도메인 스토리는 공통 기반이고 기능 명세는 시스템 구현 수준의 구체성을 가져야 하므로, 두 문서를 같은 것으로 다루면 안 된다고 말했다.
• 책은 개발을 요구사항을 확정한 뒤 구현하는 일보다, 요구사항과 구현을 주기적으로 지속 논의하는 과정으로 본다고 소개했다.
• 도메인 스토리에서 ‘A로서 나는 B를 위해 C를 한다’ 형식의 유저 스토리를 만들고 이를 바탕으로 요구사항을 도출한다고 설명했다.
• 도메인 전문가는 자동화 가능성과 업무 프로세스 재편 가능성을 잘 모를 수 있어, 문제 파악과 해결책 설계를 구분해야 한다고 했다.

07도메인 모델·테스트·AI 활용

• 12장은 도메인 지식을 소프트웨어에 가까운 방식으로 압축한 형태를 도메인 모델이라고 설명했다.
• 작업 객체는 엔티티 등 모델로, 도메인 스토리에서 해당 객체가 쓰이는 시나리오는 메서드로 옮길 수 있다고 소개했다.
• 단순 getter·setter보다 업무 맥락을 반영한 메서드가 도메인 규칙 위반을 방지하는 표현적인 모델에 가깝다고 설명했다.
• 세분화된 도메인 스토리의 시나리오는 행동 기반의 E2E 수용 테스트로 옮길 수 있다고 말했다.
• 도메인 스토리의 선후 관계는 TypeScript 등의 assert로 조건이 충족되지 않으면 다음 단계로 진행하지 못하게 반영할 수 있다고 했다.

08용어 사전