[220719]

1. 공지

• 개인면담전에 직업선호도검사 L형, IT직무 기본역량검사 하기

2. 협업툴 강의

• 협업툴 : https://miro.com/app/
• 서비스런칭 : 평균 3~6개월 소요, cloud, saas를 사용해서 빠른 서비스 런칭이 가능해짐.

1. 주요협업툴

코딩 : Github => svn와 차이점 알아두기!

baseline

• 계속 변경된 문서 또는 소스파일의 승인된 리비전
• 변경되는 문서 또는 소스파일이 시작되는 지점

Revision(리비전)

• 버전관리의 특정 시점을 가르킴

Branch(브랜치)

Commit(커밋)

• 내 로컬에 이력이 남는 것

Conflict(충돌)

Branch전략

Git Flow

• master(런칭, tag기준으로 배포)
• Hotfix(런칭 이후 버그수정)
• Develop(개발이 완료된 최신브랜치, 신규개발된 내역이 처음 합쳐지는 브랜치)
• release(develop브랜치를 기준으로 생성, 배포)
• feature(개발하는 기능만큼 생기고 사라지는 브랜치)

메시징 : slack => 실시간 커뮤니케이션, 장애대응

white board : miro => 실시간 설계도 작성 용이

• 코딩을 잘하는 것도 중요하지만 문서화를 잘 하는 것도 정말 중요하다! 기획문서, 설계문서, 회의록을 남겨놓으면 좋다. (취업준비 시, 중요한 포인트를 잡기 쉬움)

Document Sharing : confluence

Project Manager : Jira => 이슈관리

2. Event Storming

• 장점 : 참여한 인원들의 프로젝트 설계 이해도가 높아짐, 서로간의 입장에 대해 잘 이해를 하게 됨.
• 단점 : 시간이 오래걸림
  
  
  

aggregate를 찾는 것이 목적.

1. 도메인이벤트를 나열하고 정리한다.
2. 커멘드, 외부시스템, 액터, 리드모델, 폴리시를 순서대로 붙인다.
3. aggregate를 찾고, 재정렬한다.

• 참고사이트 : https://miro.com/miroverse/event-storming/

3. 협업프로젝트 : 도서관리 시스템 설계

11시 반까지!
사내도서관리 시스템 설계

피드백

• 서비스이름은 나중에 뽑음. 서비스이름을 미리 지정하면 선입견이 생김. 도메인이벤트부터 쓰기.
• 도메인이벤트는 없고 policy만 많음. 유저가 반납에 대한 이력이 있는 경우, 연체에 대한 이력이 있는 경우, 도서예약을 미리 한 사람이 있는지 확인. 조건은 policy, 대출금지됨은 도메인이벤트, 기간계산은 policy. (유저의 등급별 기간선정이 필요할 경우)
• read model = DB, 우리가 저장할 필드명이 들어감.
• 도메인이벤트를 하나로 묶는게 aggregate.
• 내가 만들기 싫은 걸 external system을 붙임.
• 도메인이벤트(과거형)를 먼저 뽑아보고, policy(명령어, 명사로 끝나게, request, 파라미터), command 붙이기.
• 포스트잇 색깔 꼭 지키기!
• read model : 필요한 데이터베이스 수, 내가 이 도메인이벤트를 처리할 때 필요한 정보는 뭔지 적는 것.
• policy : if문
• 도서라는 말을 빼도 말이 되면 외부서비스! (external system)
• 마이페이지라는 게 정말 서비스일까? 리드 모델 밖에 없을 것이다. 마이페이지가 들고 있을 정보는 없이 그냥 불러와서 뿌려주기만 해도 되기 때문!
• DB를 쪼갤 지 합칠 지는 프로젝트에 따라 선택적으로 판단할 것. 각각 장단이 있기 때문에.
• 서로 어떻게 통신할까를 정해보기!
• decorator 패턴, 프록시서비스.
• 결제, 회원 : 하나의 서비스, 그 외 : 분산된 서비스 (빠른 딜리버리 필요)