업데이트

2020-04-19 16:58:51 +09:00
parent ea3477b7a4
commit 9e05fbb18a
1 changed files with 24 additions and 11 deletions
--- a/README.md
+++ b/README.md
@@ -112,34 +112,47 @@

 * 이벤트스토밍 결과:  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)
+
+- TO-BE 조직
  ![image](https://user-images.githubusercontent.com/487999/79682333-500f3f00-825c-11ea-8a48-f51367a1592d.png)


+- 이벤트 도출 

- 과정중 도출된 잘못된 도메인 이벤트들을 걸러내는 작업을 수행함
-    - 주문시>메뉴카테고리선택됨, 주문시>메뉴검색됨 :  UI 의 이벤트이지, 업무적인 의미의 이벤트가 아니라서 제외
+    - 과정중 도출된 잘못된 도메인 이벤트들을 걸러내는 작업을 수행함
+        - 주문시>메뉴카테고리선택됨, 주문시>메뉴검색됨 :  UI 의 이벤트이지, 업무적인 의미의 이벤트가 아니라서 제외
+
+- 폴리시 매핑  
+
+- 커맨드/유저
     
- 어그리게잇: app의 Order, store 의 주문처리, 결제의 결제이력은 그와 연결된 command 와 event 들에 의하여 트랜잭션이 유지되어야 하는 단위임.
+- 어그리게잇: app의 Order, store 의 주문처리, 결제의 결제이력은 그와 연결된 command 와 event 들에 의하여 트랜잭션이 유지되어야 하는 단위로 그들 끼리 묶어줌

-      ![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)
-
- 비기능적 요구사항에 대한 반영 - 컨테스트 매핑/이벤트 드리븐 설계
+- Bounded Context 도출
    - 도메인 서열 분리 
        - Core Domain:  app(front), store : 없어서는 안될 핵심 서비스이며, 연견 Up-time SLA 수준을 99.999% 목표, 배포주기는 app 의 경우 1주일 1회 미만, store 의 경우 1개월 1회 미만
        - Supporting Domain:   marketing, customer : 경쟁력을 내기위한 서비스이며, SLA 수준은 연간 60% 이상 uptime 목표, 배포주기는 각 팀의 자율이나 표준 스프린트 주기가 1주일 이므로 1주일 1회 이상을 기준으로 함.
        - General Domain:   pay : 결제서비스로 3rd Party 외부 서비스를 사용하는 것이 경쟁력이 높음 (핑크색으로 이후 전환할 예정)
+
+- 컨텍스트 매핑
+
+- 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)
+
+
+- 비기능적 요구사항에 대한 반영 - 컨테스트 매핑/이벤트 드리븐 설계
    - 마이크로 서비스를 넘나드는 시나리오에 대한 트랜잭션 처리
        - 고객 주문시 결제처리:  결제가 완료되지 않은 주문은 절대 받지 않는다는 경영자의 오랜 신념(?) 에 따라, 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)
+  ![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)


 - 헥사고날 아키텍처 다이어그램 도출