유스 케이스로 시작하는 도메인 중심 설계

유스 케이스에서 시작하는 도메인 중심 설계 기술을 소개합니다.

태풍으로 예정이 없어졌기 때문에 오랜만에 확실히 썼습니다.

개요

최근 DDD에 의한 개발이 번성하네요.
DDD는 오로지 도메인을 분석해 모델링해 나가기 위한 수법입니다만, 유스 케이스 구동 개발과는 매우 궁합이 좋다고 느끼고 있습니다.
그래서 유스 케이스 구동 개발부터 시작하는 도메인 구동 설계의 방법을 소개하고 싶습니다.
클래스를 도메인 수준으로 떨어뜨리는 것을 목표로 합니다.
유스 케이스에서 실장까지의 흐름이 잡히면 생각합니다.

0. 기능 요구 사항

어떤 시스템을 개발하더라도 요구라는 것은 존재합니다.
'고객이 가진 문제는 무엇인가'를 이해하고 '시스템이 무엇을 제공할 수 있는지'를 정의하는 단계입니다.

예로서 「식생활의 관리가 하고 싶다.」를 바탕으로 설계해 보고 싶습니다.

기능 요청

매식 식사 메뉴를 등록할 수 있다.

재료를 등록할 수 있다.

매식 식사를 메뉴에서 선택하여 등록할 수 있다.

과거에 먹은 식사의 내용을 확인할 수 있다.

1. 도메인 모델링

첫 번째 도메인 모델링에서는 모델 후보를 씻어내는 것을 목표로 합니다.
여기서 씻어낸 모델 후보를 도메인 모델로 키워 가게 됩니다만, 최초의 단계에서 완벽하게 씻어낼 수 없기 때문에 너무 시간을 지나치게 하는 것은 득점이 아닙니다.
이후의 유스 케이스 모델링이나 견고한 모델링에서는 여기에서 씻어낸 모델을 수정하거나 추가한 리하면서 키워 나가게 되기 때문에 최초로 모두 씻어낼 수 없어도 신경 쓰지 않습니다.
모델을 찾는 방법은 고객과의 청각으로 나온 단어가 키가 됩니다.
고객과의 대화에서 나온 단어 중 명사가 모델 후보로 동사는 행동 후보가 됩니다.

2. 유스 케이스 모델링 그런 다음 유스 케이스 모델링을 수행합니다. 유스 케이스 설명은 다음 사항에 주의하여 쓴다. 유스 케이스 분석 결과를 검토하고 도메인 모델을 적절하게 업데이트합니다. 주어, 술어, 목적어로 간결하게 쓴다. 사용자와 시스템의 양쪽을 작성한다. 유스 케이스 다이어그램 유스 케이스 설명 - 재료를 등록할 수 있다 기본 1 사용자는 재료 등록 화면에 액세스합니다. 기본 2 시스템은 재료 등록 화면을 표시합니다. 기본 3 사용자는 재료 이름과 칼로리를 입력하고 등록 버튼을 클릭합니다. 기본 4 시스템은 입력 내용을 체크하여 데이터 스토어에 등록한다. (대체 1) 기본 5 시스템은 등록 완료 화면을 표시한다. 대체 1 시스템은 입력 내용에 결함이 있음을 재료 등록 화면에 표시합니다. - 매식 식사 메뉴를 등록할 수 있다 기본 1 사용자는 메뉴 등록 화면에 액세스한다. 기본 2 시스템은 메뉴 등록 화면을 표시합니다. 기본 3 사용자는 재료를 선택하고 메뉴 이름을 입력하고 등록 버튼을 클릭합니다. 기본 4 시스템은 입력 내용을 체크하여 데이터 스토어에 등록한다. (대체 1) 기본 5 시스템은 등록 완료 화면을 표시한다. 대체 1 시스템은 입력 내용에 결함이 있음을 메뉴 등록 화면에 표시합니다. - 매식 식사를 메뉴에서 선택하여 등록할 수 있다 기본 1 사용자는 식사 등록 화면에 액세스한다. 기본 2 시스템은 식사 등록 화면을 표시합니다. 기본 3 사용자는 메뉴와 날짜, 라벨을 입력하고 등록 버튼을 클릭합니다. 기본 4 시스템은 입력 내용을 체크하여 데이터 스토어에 등록한다. (대체 1) 기본 5 시스템은 등록 완료 화면을 표시한다. 대체 1 시스템은 입력 내용에 결함이 있음을 식사 등록 화면에 표시합니다. - 과거에 먹었던 식사의 내용을 확인할 수 있다 기본 1 사용자는 식사 확인 화면에 액세스한다. 기본 2 시스템은 식사 등록 화면을 표시합니다. 기본 3 사용자는 날짜를 선택하고 확인 버튼을 클릭합니다. 기본 4 시스템은 입력 내용을 확인하여 데이터 스토어로부터 데이터를 일시 오름차순으로 취득한다. (대체 1) 기본 5 시스템은 식사 확인 화면에 결과를 표시합니다. 대체 1 시스템은 입력 내용에 결함이 있음을 식사 확인 화면에 표시합니다. 3. 견고한 분석 견고한 다이어그램은 유스 케이스 설명과 도메인 모델을 기반으로합니다. 유스 케이스 기술의 명사는 엔티티 후보이며 동사는 행동 후보가 된다. 또한 견고성 다이어그램의 엔티티는 도메인 모델과 과부족없이 일치해야합니다. 견고성 분석 결과를 검토하고 사용 사례 설명과 도메인 모델을 적절하게 업데이트합니다. 견고한 다이어그램 4. 시퀀스 다이어그램 글쎄, 강건한 그림까지 끝났습니다. 다음은 시퀀스 다이어그램을 그립니다. 시퀀스 다이어그램이 그리면 클래스 다이어그램의 관계를 알고 상세 설계를 할 수 있었던 것도 마찬가지입니다. 시퀀스 다이어그램은 도메인 모델의 모델과 견고한 다이어그램의 컨트롤러를 사용하여 그립니다. 여기까지는 순조롭게 할 수 있었습니다. 조속히 처음 보고 싶습니다만 시퀀스 다이어그램을 그리기 시작해서 뭔가 이상한 것을 알아차릴 것입니다. 그래, 이대로라면 시퀀스도를 그릴 수 없습니다. 시도에 시퀀스 다이어그램을 그려 보겠습니다. 오! 뭔가 그릴 수 있었습니다. 너무 보통의 시퀀스도를 그릴 수 있었습니다. 「메디시메데타시」는 아니네요＾＾； 하고 싶은 건 DDD였어요. 무엇이 잘 되지 않았을까. 시퀀스 다이어그램은 견고성 다이어그램을 바탕으로 그려 나가는 힘든 견고성 다이어그램이 나빴던 것입니다. 그래서 견고한 그림을 다시 그려 보겠습니다. 수정된 견고한 다이어그램 위는 애플리케이션(유스 케이스)과 집계 루트와 도메인 모델과 리포지토리를 사용해 재작성한 것입니다. 그러면 위의 견고성 다이어그램을 바탕으로 다시 한 번 시퀀스 다이어그램을 그려 보겠습니다. 시퀀스 다이어그램 그런 순서도가 되었습니다. 생성 된 시퀀스 다이어그램은 유스 케이스 설명과 일치하는지 (요구 사항을 충족하는지) 확인하고 견고한 다이어그램과 도메인 모델과 일치하는지 검토합니다. 5. 클래스 다이어그램 시퀀스 다이어그램과 견고한 다이어그램에서 도메인 모델을 업데이트하여 클래스 다이어그램을 만듭니다. 힘든 달리기로 만들었기 때문에 보기 흉한 점은 있을까 생각합니다만 1번째의 유스 케이스만은 어떻게든 완성했습니다. 제대로 재검토하면 수정하고 싶은 부분은 많이 나온다고 생각합니다만, DDD에 떨어뜨릴 때까지의 흐름이 흠뻑 잡으면 충분하다고 생각합니다.