쇼핑몰 서비스 업무 흐름
쇼핑몰 서비스의 업무 흐름은 가장 기본적인 구매자의 제품 구매 사례 관점에 대해 알아보겠습니다. 구매자는 구매하고자 하는 상품과 구매 수량을 입력해서 상품을 주문하고, 주문한 상품의 배송상태를 확인합니다. 식별한 마이크로서비스들 간의 업무 흐름으로, 먼저 구매자는 상품 구매를 하기 위해서 화면을 통해 구매하려는 상품과 구매 수량을 입력합니다.
구매 정보가 입력되면 Account 서비스로 구매자 이름으로 입력된 사람이 회원인지 아닌지 확인합니다. Account 서비스에 구매한 상품의 배송을 위한 주소를 가져와 상품을 배송 받을 주소로 설정합니다. 그리고 구매하기 위해 입력한 상품 이름으로 Product 서비스에서 해당 상품의 가격이 얼마인지 요청해서 전달 받은 후 입력한 구매수량에 맞는 총 구매 비용을 계산합니다.
이렇게 진행된 상품 구매는 Purchase 서비스의 데이터베이스에 저장하면서 상품구매가 완료됩니다. 이렇게 구매가 완료된 상품은 상품 수취자 주소와 함께 구매자에게 상품을 배송하기 위해 Delivery 서비스로 전달되게 됩니다. 배송업체를 통해 Delivery 서비스로 상품의 배송상태가 업데이트 됩니다. 구매자는 Delivery 서비스를 통해 상품의 배송정보를 조회합니다.
Key Concept
이후 마이크로서비스 구현에서도 위의 객체에 대해 구현을 진행합니다. 도메인 모델링을 위해 모델의 프로젝트를 생성하고 각 유형의 모델이 위치할 패키지를 만들어봅니다.
모델 패키지 구조
이렇게 모델링을 위한 패키지를 구성하면 이후 도메인 모델을 소스코드 패키지와 동일한 패키지 이름으로 관리할 수 있게 됩니다. 모델을 코드로 구현하거나 코드의 내용을 모델과 비교를 통한 검증을 쉽게 할 수 있습니다. 그럼 먼저 모델링을 하기에 앞서 모델 패키지 구조를 화면과 같이 Model, Repository, Service로 구성합니다. 전략적 설계를 통해 식별한 마이크로서비스 중에서 먼저 Account, 즉 계정 서비스를 모델링합니다.
Account Domain Model
이 Account 서비스는 이 시스템을 사용하는 사람 또는 역할을 관리하는 서비스로 이 시스템의 사용자는 등록정보의 키로 사용되는 아이디, 사용자 정보인 이름, 이메일 주소, 주소 정보를 갖고 있습니다. 이 중 주소 정보는 배송받을 곳의 우편번호와 주소를 갖고 있습니다. 또한 이 시스템의 사용자는 제품을 판매하는 판매자와 판매자가 등록한 제품을 구매하는 구매자의 2가지 유형으로 분류됩니다.
또한 판매자와 구매자는 각자의 판매, 구매 실적에 따라 맴버십 등급을 부여 받을 수 있습니다. 모델링은 보통 영문으로 작성하지만 이 서비스를 담당하는 모든 사람이 모델 을 통해 비즈니스의 이해를 위해 각 객체별 별칭 또는 비교란에는 한글명을 적고 실제 이름은 영문으로 표기합니다.
Account 서비스를 이해하기 쉽게 한글로 표현했지만, 실제 구현을 위해서는 화면과 같이 Attribute들의 이름을 영문으로 표현하고 또한 데이터 타입도 정의합니다. 그리고 각 객체의 유형, Stereotype 등 유형을 식별해야 합니다. 고유한 식별자와 변화 가능성이라는 특징을 갖는 객체를 Entity로 식별합니다. 즉 다른 객체와 식별되어야 하고, 또 생명주기 동안 형태나 내용이 변경될 수는 있지만 연속성이 유지되어야 하는 경우 Entity로 식별을 합니다.
그리고 Entity와 같이 모델을 표현하고는 있으나 식별성이 없는 경우 값 객체, 즉 Value Object로 식별합니다.
이 Value Object는 상태를 변경할 수 없는 객체로 객체의 개별 속성이 수정되거나 삭제되지 않고 Value Object 전체가 생성되거나 삭제되는 방식으로 동작하게 됩니다. Account 서비스의 각 객체들을 식별해 보면 Account는 Entity로 Address는 Value Object로 식별합니다.
이 도메인 모델링을 진행한 후 도메인 모듈의 설계를 진행할 수 있습니다. 인터페이스인 AccountService와 AccountService를 Implementation 하는 AccountLogic 객체 그리고 Account 의 데이터를 저장소에 대한 인터페이스인 AccountRepository 인터페이스를 표시합니다. 여기서 도메인 모듈이란 도메인 모델을 담고 있는 Java의 패키지나 C#의 네임스페이스를 뜻합니다.
도메인 모듈의 설계는 서로 다른 모듈에 있는 객체 사이에 낮은 결합도를 유지하기 위해 사용합니다. 도메인 모듈은 도출된 마이크로서비스 단위로 모듈을 정의합니다. 도메인서비스, Account에서의 AccountService란 도메인 고유의 작업을 수행하는 오퍼레이션으로 Aggregate에서 수행되지 못하는 동작이 필요한 경우 정의되어 사용됩니다.
Product Domain Model
이 Product 서비스는 이 시스템을 통해 판매되는 상품의 정보를 정의하는 서비스로 상품코드, 상품명, 가격 그리고 상품별로 하나의 상세정보를 갖고 있으므로 상품 객체를 식별합니다. 그리고 상품의 상세 정보에는 상품의 사이즈와 색상 정보를 갖고 있으므로 표준 타입의 사이즈와 색상을 식별합니다. 특히 이 표준 타입은 상품의 사이즈는 S, M, L, XL이 있으며 색상은 빨간색부터 보라색까지 총 7가지의 색상이 있습니다.
Account에서 Entity와 Value Object를 식별하고, Root가 되는 Entity를 Aggregate으로 식별했었는데, Product에도 동일하게 진행합니다. Product 서비스의 도메인 모델에서는 상품, 즉 Product가 다른 형태의 상품과 식별자를 통해 구별되어야 하고 상태가 변경될 수 있어야 하기 때문에 Entity로 식별합니다. 그리고 상품 상세정보인 ProductdDescription은 상품 Entity를 설명하는 객체로 값 객체로 정의할 수 있습니다.
ProductDescription 객체의 속성인 컬러와 사이즈가 변경되는 경우 값 객체의 특성상 수정이 아닌 새로운 주소를 생성한 후 기존 사이즈와 색상의 상세정보를 대체하는 방식으로 변경해야 합니다. 만약 상품의 사이즈와 색상별로 가격이 다른 경우에는 ProductDescription은 값 객체가 아닌 Entity로 식별할 수 있습니다. 그러나 여기서는 사이즈와 색상은 Product를 설명하는 속성을 나타내므로 값 객체로 식별을 하였습니다.
Purchase Domain Model
이 Purchase 서비스는 구매자의 상품 구매를 정의하는 서비스로 구매는 구매한 사람, 즉 구매자와 구매한 상품, 수량, 총 금액, 그리고 이 구매한 상품을 받는 사람, 좀 더 구체적으로 얘기하면 받는 사람의 이름, 주소, 우편번호가 있습니다. 구매한 상품을 받는 사람은 역할에 따라 명확한 의미의 용어로 바꿔서 수취자라고 정의를 합니다.
또한 구매자 정보도 Account 서비스를 통해 이름과 할인을 위한 멤버십 정보를 갖는 구매자, 즉 Buyer라는 명확한 용어로 정의합니다. 마찬가지로 구매한 상품도 구매품으로 정의합니다. Purchase에 대해 도메인 모델링을 진행합니다. Purchase 서비스의 도메인 모델에서는 구매는 Purchase로, 구매자는 Buyer, 구매품은 PurchasedItem, 수취자는 Recipient의 용어로 정의하였습니다. Purchase는 다른 형태의 구매와 식별자를 통해 구별되어야 하고 상태가 변경될 수 있어야 하기 때문에 Entity로 식별합니다.
Buyer, PurchasedItem, Recipient는 Purchase를 설명해 주는 객체들로 값 객체로 식별합니다. 그리고 구매를 위해서는 신용카드 정보를 입력하게 되는데, 이 정보는 카드번호와 유효기간의 정보를 갖고 있으며, 이 또한 구매에 사용된 카드 정보를 표현하는 것으로 값 객체로 식별합니다.
Delivery Domain Model
이 Delivery 서비스는 구매가 완료된 상품이 고객에게 배송되는 정보를 정의하는 서비스로 배송은 배송될 제품과 제품을 받을 수취자 정보가 있으며 배송이 진행됨에 따라 배송상태를 갖고 있습니다. 배송될 제품은 배송품으로, 배송 받는 사람은 수취자로 명확한 의미의 용어로 정의합니다. 수취자는 수취자 이름, 상품을 받을 주소와 우편번호 그리고 부재 시 연락할 전화번호로 구성합니다.
Delivery 서비스에 대해 도메인 모델링을 진행해 보면, Delivery 서비스의 도메인 모델에서는 배송은 Delivery로, 배송품은 DeliveryItem, 수취자는 Recipient의 용어로 정의합니다. Delivery는 다른 형태의 구매와 식별자를 통해 구별되어야 합니다. 배송 현황에 따라가 변경될 수 있어야 하기 때문에 Entity로 식별합니다. Recipient와 DeliveryItem은 Delivery를 설명해 주는 객체들로 값 객체로 식별합니다.
Domain Modeling 결과
쇼핑몰 서비스에서 상품 구매와 관련된 Account, Purchase, Product 및 Delivery에 대해 도메인 모델링을 같이 진행합니다. 마이크로서비스는 각자 독립적으로 하나의 기능을 완벽히 수행해야 한다고 설명했던 것을 기억합니다. Account 서비스는 이 쇼핑몰 시스템을 사용하는 판매자 또는 구매자 정보의 관리를 완벽히 수행할 수 있도록 설계가 되었습니다.
Product, Purchase, Delivery 서비스 또한 각자 담당하는 기능을 잘 수행할 수 있도록 설계가 되었습니다. Purchase 서비스를 보면 사용자 정보를 관리하는 Account, 상품정보를 관리하는 Product 서비스가 없더라도 담당하고 있는 구매 기능을 수행하기 위해 Buyer와 Recipient 객체에 Account의 맴버십 등급, 주소, 우편번호들을 갖고 있습니다. 상품 구매를 위해 Product 의 상품과 가격 정보를 PurchasedItem 객체에 갖고 있습니다.
또한 Delivery 서비스도 배송품, 수취자의 정보를 Product 서비스와 Account 서비스와 별도로 갖고 있으므로 다른 서비스에 영향 없이 독립적으로 동작할 수 있도록 설계가 되었습니다. 전술적 설계를 통해 마이크로서비스 내부를 설계하고, 각 마이크로서비스 간 연동 관계를 식별함으로써 Entity와 값 개체, 표준 타입 식별하고 Aggregate을 식별하는 도메인 모델 설계와 Service Interface와 Repository Interface를 정의하는 도메인 모듈 설계, 마지막으로 각 마이크로 서비스 동기/비동기 연동을 설계하는 마이크로서비스 설계까지 진행을 해보았습니다.
마이크로서비스의 설계를 도메인 주도 설계의 전략적 설계 및 전술적 설계 방식을 따르고 있습니다. 그렇지만 마이크로서비스의 구현을 항상 도메인 주도 설계 방식으로만 설계해야 하는 것은 아닙니다. 마이크로서비스 아키텍처에 가장 바람직한 구조 및 설계 방식을 '도메인 주도 설계'라 보고 이 기법을 채택해서 설명하고 있습니다.
하지만, 프로젝트의 상황이나 업무 성격에 따라 도메인주도설계의 전략적 설계를 기반으로 마이크로서비스를 도출합니다. 마이크로서비스의 내부구조는 도메인주도설계의 전술적 패턴을 적용하지 않은 구조로도 설계할 수 있습니다. 하지만 클라우드 기반의 마이크로서비스 아키텍처를 적용한 애플리케이션을 개발한다면 클라우드와 마이크로서비스 아키텍처의 수많은 장점들을 활용하기 위해 마이크로서비스를 도메인 주도 설계 기법을 통해 설계하는 것이 바람직합니다.
'SW > 마이크로서비스' 카테고리의 다른 글
| 마이크로서비스 : Spring Boot 프로젝트 생성 : 방법, 구현, 예제 (0) | 2020.05.27 |
|---|---|
| 마이크로서비스 : 구현하기 위한 개발환경 구축 방법 : 오픈소스 종류, 활용 (0) | 2020.05.26 |
| 마이크로 서비스 : 애그리게잇 식별 방법 : 개념, 정의, 개요 (0) | 2020.05.24 |
| 마이크로서비스 : 엔티티, 값객체, 표준 타입 식별하기 : 정의, 개요, 방법 (0) | 2020.05.23 |
| 마이크로서비스 : 내부 설계를 위한 전술적 설계 및 주요 개념 : 정의, 개요, 설명 (0) | 2020.05.22 |