내배캠 5주 2일 차

오늘은 TodoList 과제를 진행하기 앞서 Use Case Diagram에 대해 좀 공부 했다.

그리고 DDD(Domain Driven Design)에 근거해서 설계를 진행해봤다.

 

아래는 Use Case Diagram에 대해 배운 것을 정리해 본 것이다.

시스템 외부에서 시스템과 상호작용하는 객체
액터는 졸라맨으로 그린다.
액터는 사람일 수도 있고 또 다른 시스템이 될 수도 있다.
액터에는 2가지 종류가 있다.
1. Primary Actor : 시스템을 직접 이용한다. -> 시스템 왼쪽에 그린다.
2. Secondary Actor :  프라이머리 액터가 목적을 달성하기 위해 도움을 주는 액터이다. <<actor>>라고 표기하고 시스템 오른쪽에 그린다.

유스케이스 (Usecase)
시스템 내에 있는 기능들이다.  타원형으로 그린다.

관계 (Relationship)
선 또는 화살표로 나타내며 액터와 유스케이스, 유스케이스 와 유스케이스가 서로 상호작용 한다.
관계는 총 4가지가 있다.

1. 연관 관계 (Association)
유스케이스와 액터 사이에 상호작용이 있다는 뜻으로 실선으로 표시 --> 액터가 기능을 이용한다.
ex) 
    고객(Primary)이 은행 시스템에서 로그인과 결제를 한다. 
    은행(Secondary)은 결제 기능을 이용하지만 로그인 기능은 필요 없다.

2. 포함관계 (Include)
포함 관계는 두 개의 유스케이스 간의 의존성을 나타낸다.
하나의 기능이 실행될 때 특정 기능이 반드시 실행될 때 포함관계가 된다.
기존의 유스케이스에서 포함된 유스케이스 방향을 가르키는 점선 화살표를 그리고 <<include>>라고 표기한다.
ex)
    고객이 로그인할 때 로그인 정보가 맞는지 확인한다.
    로그인과 로그인정보확인이 포함 관계이다.

3. 확장 관계 (Extend)
확장 관계는 두개의  유스케이스 간의 확장성을 나타낸다.
하나의 유스케이스가 실행될 때 특정한 상황에서 실행되는 유스케이스이다.
확장된 유스케이스에서 기존의 유스케이스 방향으로 점선 화살표를 표시하고 <<extend>>를 표기한다.
ex)
    로그인할 때 실패하면 오류를 보여준다.
    로그인시마다 오류를 보이는 것이 아니다.

4. 일반화 관계 (Generalization)
일반화 관계는 부모 유스케이스와 자식 유스케이스의 관계를 나타낸다.
자식 유스케이스에서 부모 유스케이스 방향으로 삼각형 실선 화살표를 보낸다.

확장관계와의 차이점
일반화 관계는 상속이라는 특징 때문의 부모의 관계 및 기능을 모두 물려받는다.
그러나 확장관계는 속성을 물려받은 것이 아니기 때문에 관계를 만족시킬 필요가 없다.

작성 순서
1. 시스템의 정의
2. 액터 정의
3. 유스케이스 정의
4. 관계 정의
5. 유스케이스 구조화

 

과제는 할일(Todo)에 관한 것이였다.

흔히 하는 자기계획에 필요한 Todo를 API로 만드는 것이였다.

단계가 4개로 나뉘어져있지만 먼저 step1(필수)에 대해서만 진행 해 보았다.

 

step1은 Todo를 생성, 조회(단건, 전체), 수정, 삭제 하는 것이었다.

또한 Todo는 제목, 내용, 작성일, 작성자가 있다.

요청에 따라서 Todo 내용을 반환한다.

 

아래는 DDD를 텍스트로 적어본 것이다.

Step1에 대한 DDD(Domain Driven Design)를 작성하는 중 --> 나중에 step이 증가될 때 내용이 수정될 수 있음.

1. 액터 정의
    사용자 - 글(ToDoList)를 작성함

2. Domain Event 나열
    할 일 카드(ToDoList)
    ToDoList 생성됨
    ToDoList 조회됨
    ToDoList 수정됨
    ToDoList 삭제됨

3. Command 설정
    할 일 카드(ToDoList)
    ToDoList 생성됨
    ToDoList 조회됨
    ToDoList 수정됨
    ToDoList 삭제됨

4. External System 표시
    현재는 없음
    제목, 내용, 날짜, 작성자 이름은 db에 저장 가능함
    나중에 필요한 파일이 생길 시 외부 시스템 필요?

5. Actor 표기
    사용자는 생성, 조회, 수정, 삭제 모두 가능함

7. Event Grouping 및 Model, Aggregate 정의
    ToDoList Model
        ToDoList 생성됨
        ToDoList 조회됨
        ToDoList 수정됨
        ToDoList 삭제됨

    Aggregate
        ToDoList 생성됨
        ToDoList 조회됨
        ToDoList 수정됨
        ToDoList 삭제됨

8. BoundedContext 정의

9. Data 정의

    ToDoList
        Id : Long
        Title : String
        Content : String
        Date --> 일단 String으로 구현
        Writer : String

 

 

아래 그림은 그림으로 표시해 봤다.

Use Case Diagram

DDD에 근거한 설계

 

일단 설계는 된 것 같아서 이제 그걸 구현하면 될 거 같다.