04/09(수) 시스템 설계 문서화
AI 서비스 기획 공부
시스템 설계 문서화
= 협업 기준선, 기술 커뮤니케이션 비용 감소
= 기술적 리스크 사전에 발견
= 운영관점 기능 포함
( -> 이벤트 스토밍 -> ) 요구정의서 ( -> 시나리오 -> 테스트 흐름) -> 정책 정의서 -> 시스템 설계 문서
요구정의서 - 기능 요구
정책 정의서 - 조건/제약 정리
플로우차트 - "도메인 지식을 이해한다."
도메인지식 = 업무 영역
"결제 업무에 해당하는 지식"
"어떤 산업 도메인"
도메인 바꾸기 쉽지 않음
시퀀스 다이어그램 - 시간별로 (기획자가 만들기 힘듦)
2) 데이터 흐름
DFD
ERD Entity Relationship Diagram (DB 구조와 연결성)
3) 역할 기반 구조 rbac Role based Architecture
이벤트 = 데이터가 변경되는 모든 행위
이벤트 스토밍 개념
domain driven design (도메인 주도 설계)
전술적 설계 vs 전략적 설계
전략적 설계 -> 시스템에 대한 큰 그림 (빅 픽쳐)
전술적 설계 -> 상세하게 구현해나가는 방식을 결정하고 설계
이벤트 스토밍 -> 빅픽처를 위함
같은 도메인 지식을 가지고 같은 용어로 이야기할 수 있게 생각을 통일
같은 용어 => 유비쿼터스 랭귀지
모든 이해관계자 포함( 기획자, 개발자, 디자이너, 데이터베이스 관리자, qa//)
작업 순서
1) domain event = 피동태 형식, 데이터 변경 있을 것들 ( 조회, 검색 X / 등록, 추가, 삭제, 변경 O )
*삽입이 있으면, 수정과 삭제는 세트 (데이터를 넣으면 그 데이터는 수정, 삭제 가능)
가입 -> 수정 삭제 가능
등록 -> 수정 삭제 가능
마구 등록 후, 중복 없애고, 시간 순서로 나열 (완전히 맞을 필요는 없음)
2) external system = 외부 api 호출 해야 할 때 (남이 만든 것 가져다 쓸 것)
*그냥 중간에 붙이면 됨
*시스템의 규모를 결정하는 일
3) command = 어떠한 이벤트 만들기 위한 사용자의 액션
명확한 커맨드 이름을 가져야 함
*기계적으로 무조건 붙는다고 생각하기
domain event = 회원 가입됨 => command = 회원가입
4) hot spot = 고민해야 할 거리들
domain event = 회원 가입됨 => 재가입 조건은?
domain event = 카테고리 등록됨 => 몇개로 운영?
5) actor = 커맨드를 하는 주체 (모든 커맨드에 붙여야 함)
*뭉치지 말기, 각자 그냥 붙이면 됨 = 권한 정책
=> 권한 설계
6) aggregate = 이벤트에 영향받는 데이터의 집합 (변경되는 데이터들의 묶음)
* 화살표는 함부로 그리지 말기
+ 그 전에 aggregate 같은 것 끼리 묶는다. (00 컨택스트)
+ 같은 컨택스트 내에서는 화살표 사용 안함
7) policy
- 둘 중에 한 가지만 될 수 있는 상황 (승인/거절)에 검증해야 하는 정책에서 사용
흐름 상 외부 컨택스트와 연결해야 할 때
이때 흐름을 만들어야 할 때 화살표를 사용함.
=> 정책 설계
검색 조회는 얼마든지 나중에 추가할 수 있기 때문에
추가 기획해서 넣으면 됨
어렵다. . . .
자꾸 화면을 생각하면서 구상하니까
어드민 생각이 안난다.
이렇게 하는 게 아닌 것 같다.
api 종류가 뭐가 있는지 알아봐야겠다. -> 외부에서 무엇을 끌어와야 하는지. 내부에서 처리할 수 없는 사항은 무엇인지 잘 확인해봐야겠다.
