diff --git a/README.md b/README.md index f700f27..e68b3b8 100644 --- a/README.md +++ b/README.md @@ -113,10 +113,10 @@ * 이벤트스토밍 결과: http://msaez.io/#/storming/nZJ2QhwVc4NlVJPbtTkZ8x9jclF2/every/a77281d704710b0c2e6a823b6e6d973a/-M5AV2z--su_i4BfQfeF - AS-IS 조직 - ![image](https://user-images.githubusercontent.com/487999/79682331-4a195e00-825c-11ea-93d6-363aef50bfb8.png) + ![image](https://user-images.githubusercontent.com/487999/79684144-2a893200-826a-11ea-9a01-79927d3a0107.png) - TO-BE 조직 - ![image](https://user-images.githubusercontent.com/487999/79682333-500f3f00-825c-11ea-8a48-f51367a1592d.png) + ![image](https://user-images.githubusercontent.com/487999/79684159-3543c700-826a-11ea-8d5f-a3fc0c4cad87.png) ## 이벤트 도출 @@ -157,22 +157,39 @@ ![image](https://user-images.githubusercontent.com/487999/79683646-63bfa300-8266-11ea-9bc5-c0b650507ac8.png) + - View Model 추가 ## 1차 완성본에 대한 기능적/비기능적 요구사항을 커버하는지 검증 - ![image](https://user-images.githubusercontent.com/487999/79682341-64ebd280-825c-11ea-966d-7d9e32f73cfe.png) - ![image](https://user-images.githubusercontent.com/487999/79682344-6c12e080-825c-11ea-8722-5395ad20f274.png) +![image](https://user-images.githubusercontent.com/487999/79684167-3ecd2f00-826a-11ea-806a-957362d197e3.png) + + - 고객이 메뉴를 선택하여 주문한다 (ok) + - 고객이 결제한다 (ok) + - 주문이 되면 주문 내역이 입점상점주인에게 전달된다 (ok) + - 상점주인이 확인하여 요리해서 배달 출발한다 (ok) + +![image](https://user-images.githubusercontent.com/487999/79684170-47256a00-826a-11ea-9777-e16fafff519a.png) + - 고객이 주문을 취소할 수 있다 (ok) + - 주문이 취소되면 배달이 취소된다 (ok) + - 고객이 주문상태를 중간중간 조회한다 (View-green sticker 의 추가로 ok) + - 주문상태가 바뀔 때 마다 카톡으로 알림을 보낸다 (?) -## 비기능적 요구사항에 대한 반영 - 컨테스트 매핑/이벤트 드리븐 설계 +## 모델 수정 + +![image](https://user-images.githubusercontent.com/487999/79684176-4e4c7800-826a-11ea-8deb-b7b053e5d7c6.png) + - 수정한 모델은 모든 요구사항을 커버함. + +## 비기능 요구사항에 대한 검증 + +![image](https://user-images.githubusercontent.com/487999/79684184-5c9a9400-826a-11ea-8d87-2ed1e44f4562.png) + - 마이크로 서비스를 넘나드는 시나리오에 대한 트랜잭션 처리 - 고객 주문시 결제처리: 결제가 완료되지 않은 주문은 절대 받지 않는다는 경영자의 오랜 신념(?) 에 따라, ACID 트랜잭션 적용. 주문와료시 결제처리에 대해서는 Request-Response 방식 처리 - 결제 완료시 점주연결 및 배송처리: App(front) 에서 Store 마이크로서비스로 주문요청이 전달되는 과정에 있어서 Store 마이크로 서비스가 별도의 배포주기를 가지기 때문에 Eventual Consistency 방식으로 트랜잭션 처리함. - 나머지 모든 inter-microservice 트랜잭션: 주문상태, 배달상태 등 모든 이벤트에 대해 카톡을 처리하는 등, 데이터 일관성의 시점이 크리티컬하지 않은 모든 경우가 대부분이라 판단, Eventual Consistency 를 기본으로 채택함. - ![image](https://user-images.githubusercontent.com/487999/79682351-73d28500-825c-11ea-9624-f31dc6189e89.png) - ![image](https://user-images.githubusercontent.com/487999/79682355-792fcf80-825c-11ea-823e-d3adf175a44f.png) ## 헥사고날 아키텍처 다이어그램 도출 @@ -753,7 +770,8 @@ Concurrency: 96.02 # 신규 개발 조직의 추가 - ![image](https://user-images.githubusercontent.com/487999/79682362-7fbe4700-825c-11ea-97d0-e72b4580bfda.png) + ![image](https://user-images.githubusercontent.com/487999/79684133-1d6c4300-826a-11ea-94a2-602e61814ebf.png) + - 마케팅팀의 추가 - KPI: 신규 고객의 유입률 증대와 기존 고객의 충성도 향상