업데이트

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: 신규 고객의 유입률 증대와 기존 고객의 충성도 향상