diff --git a/README.md b/README.md index 5a2c033..15c6e9f 100644 --- 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) - 헥사고날 아키텍처 다이어그램 도출