마이크로서비스를 위한 도메인 주도 설계 구현

in hive-137029 •  3 years ago 

마이크로서비스를 위한 도메인 주도 설계 구현

Domain Driven Design은 복잡한 문제 영역에 대한 소프트웨어 디자인에 대한 언어 및 영역 중심 접근 방식입니다. 이 용어는 Eric Evans가 2003년에 쓴 "Domain-Driven Design: Tackling Complexity in the Heart of Software"라는 저서에서 만들어졌습니다. 이 용어는 2003년에 모듈식 모놀리스를 설계하는 것과 오늘날에도 관련이 있습니다! 모듈식 모노리스는 내 다른 블로그의 주제입니다. 소매 전자 상거래 도메인의 예를 사용하여 다음 개념을 설명합니다.

영상

음성 아바타

[

Sandeep Jagtap HackerNoon 프로필 사진

](https://hackernoon.com/u/sandeep-jagtap)

@ 산딥잡탑

산딥 재그탑

ThinkWorks의 코딩 아키텍트. 자바, 코틀린, Nodejs, 클로저, 루비, 스칼라, C#.

시스템 마이크로서비스의 경계를 모델링하는 것이 어렵다는 것을 알고 계셨습니까? 코드베이스의 기술적 복잡성으로 인해 속도가 느려졌습니까? 팀이 서로의 발을 밟고 있습니까?

그러한 질문 중 일부 또는 다수가 '예'라면 Domain Driven Design은 팀에 유용할 것입니다!

도메인 주도 설계(DDD)란 무엇입니까?

Domain-Driven Design은 복잡한 문제 영역에 대한 소프트웨어 디자인에 대한 언어 및 영역 중심 접근 방식입니다.

이는 소프트웨어 산업의 집합적인 지혜, 팀이 기술 및 비즈니스 영역 모두에서 복잡성을 관리하는 소프트웨어를 만드는 동안 비즈니스 성공의 핵심에 집중할 수 있도록 하는 패턴, 원칙 및 관행의 모음으로 구성됩니다.

이 용어는 Eric Evans가 2003년에 쓴 " Domain-Driven Design: Tackling Complexity in the Heart of Software "라는 저서에서 만들어졌으며 시대를 훨씬 앞서 있었습니다!

마이크로서비스 아키텍처 시대와 매우 관련성이 높아지기 시작했습니다. 그것은 2003년에 모듈식 모노리스를 설계하는 것과 오늘날에도 관련이 있습니다! 모듈식 모노리스는 내 다른 블로그의 주제입니다!

DDD의 전술적 및 전략적 패턴

소매 전자 상거래 도메인의 예를 사용하여 다음 개념을 설명합니다. 이 도메인의 모든 것은 판매되는 "제품" 을 중심으로 해결됩니다 .

이와 관련된 코드를 보려면 다음을 확인하세요.

DDD 기본 워크샵 도메인 레이어 코드

제한된 컨텍스트, 유비쿼터스 언어 및 컨텍스트 맵과 같은 몇 가지 전략적 패턴에 대해 이야기해 보겠습니다 .

제한된 컨텍스트:

전체 전자 상거래에 대해 단 하나의 도메인 모델을 구축하는 것은 코드에서 이해하고 구현하기가 매우 어려울 것입니다. 제한된 컨텍스트는 전자 상거래 도메인을 더 작은 하위 도메인으로 분할하는 데 도움이 됩니다. 예: 재고, 장바구니, 제품 카탈로그, 주문 처리 및 배송 및 지불. 이벤트 스토밍 과 같은 기술을 사용 하여 이러한 하위 도메인 및 제한된 컨텍스트를 식별할 수 있습니다. 이제 인벤토리 경계 컨텍스트, 제품 카탈로그 경계 컨텍스트 등이 있습니다.

각 경계 컨텍스트에서 Product 는 매우 다른 동작을 가지고 있다는 점에 유의하는 것이 중요합니다 . 재고 컨텍스트에서 제품은 무게, 만료 날짜, 공급업체와 관련이 있는 반면 쇼핑 카트 경계 컨텍스트에서는 만료, 제품 공급업체가 사진에 표시되지 않습니다. 따라서 경계 컨텍스트에서 공통 제품 클래스 를 사용하는 대신 각 경계 컨텍스트에서 서로 다른 Product 클래스를 모델링하는 것이 좋습니다 .

따라서 제한된 컨텍스트는 언어적 경계입니다! 제품이 다르게 작동하는 것을 볼 때마다 극에 다른 경계 컨텍스트가 있다는 단서입니다.

하나의 제한된 컨텍스트에는 일반적으로 소수(또는 하나)의 마이크로 서비스가 있습니다.

유비쿼터스 언어:

유비쿼터스 언어는 제한된 컨텍스트 내에서 적용됩니다. 각 경계 컨텍스트에는 고유한 유비쿼터스 언어가 있습니다. 비즈니스 팀과 개발 팀 모두에서 사용하는 언어입니다. 그것은 그들이 더 잘 의사 소통하는 데 도움이됩니다.

비즈니스 팀이 데이터베이스 테이블에 대해 이야기하는 경우 개발 팀으로서 잘못 영향을 미쳤습니다.

비즈니스 및 개발 팀은 Domain Event, Domain Service, Entity, Value Object와 같은 DDD 전술 패턴을 사용하여 서로 통신해야 합니다. 나중에 (이 블로그에서) 더 자세히 설명합니다.

컨텍스트 맵:

컨텍스트 맵은 서로 다른 경계 컨텍스트 간의 관계를 정의합니다.

서로 다른 경계 컨텍스트가 서로 통신하는 방식과 서로 영향을 미치는 방식.

이제 Domain Event, Entity, Value 개체, Domain 서비스 및 Aggregate와 같은 몇 가지 전술적 패턴에 대해 이야기해 보겠습니다 .

도메인 이벤트:

도메인 이벤트는 비즈니스 팀의 관점에서 시스템에서 발생한 중요한 일을 나타냅니다. 장바구니 바운드 컨텍스트에서 장바구니 엔터티의 예를 살펴보겠습니다. ProductAddedToCart, ProductRemovedFromCart, CartCheckedOut과 같은 이벤트는 비즈니스 팀에게 중요합니다.

도메인 이벤트는 일단 발생하면 업데이트하거나 삭제할 수 없습니다 . 서로 다른 경계 컨텍스트 간의 통신 메커니즘으로 사용할 수 있습니다. 따라서 Cart에 의해 생성된 CartCheckoutEvent는 전자 상거래의 지불 경계 컨텍스트에서 사용자로부터 지불을 시작하는 데 사용할 수 있습니다.

도메인 이벤트는 느슨하게 결합되고 확장 가능한 시스템을 구축하는 데 도움이 됩니다.

또한 이벤트 소싱 시스템을 설계하기 위한 기초이기도 합니다.

실재:

장바구니 바운드 컨텍스트에서 장바구니는 엔터티입니다. 장바구니에는 제품 추가, 제품 제거, 결제 등과 같은 다양한 동작이 있습니다. 장바구니에는 이와 관련된 ID 및 수명 주기도 있습니다. 다른 카트에서 하나의 카트를 식별할 수 있습니다!

많은 객체는 기본적으로 속성에 의해 정의되는 것이 아니라 연속성과 동일성의 스레드에 의해 정의됩니다. Entity의 기본 개념은 수명 주기를 통해 스레딩되고 여러 형식을 통과하는 연속성입니다.

주로 ID로 정의된 개체를 엔터티라고 합니다.

예: 사람, 도시, 자동차, 복권 또는 은행 거래.

경기장 좌석 예약의 예, 좌석 및 참석자는 엔터티입니다. 일반 입장이라면 Seat는 Entity가 아니라 Value 객체일 필요가 있습니다.

값 개체:

장바구니의 제품 가격은 값 개체입니다.

많은 개체에는 개념적 정체성이 없습니다. 이 개체는 사물의 특성을 설명합니다. 예를 들어 같은 색상과 같은 모양의 두 마커. 하나가 손실되면 다른 마커로 교체하여 그리기를 계속할 수 있습니다.

값 개체는 사물을 설명합니다. 그것들은 우리가 그들이 누구인지가 아니라 그것이 무엇인지에 대해서만 관심을 갖는 디자인의 요소입니다.

코드 값 개체를 변경할 수 없습니다.

골재:

집계는 논리적 개념입니다. 집계의 뿌리에는 Entity가 있습니다!

장바구니 바운드 컨텍스트에서 장바구니는 집계이며 그 루트에 장바구니 엔터티가 있습니다.

집계는 데이터 변경을 위한 단위로 취급하는 관련 개체의 클러스터입니다. Aggregate 루트는 맨 위에 있으며 Aggregate에 액세스할 수 있고 전역 식별자를 갖는 유일한 엔터티입니다.

집계 내부의 다른 개체는 로컬 식별자를 가질 수 있으며 집계 외부에서 직접 액세스할 수 없습니다. 집계 루트는 외부 세계에서 액세스를 제어합니다.

하나의 마이크로 서비스에는 일반적으로 하나의 집계가 있습니다.

Aggregate 내에서 적용된 불변/일관성 규칙/비즈니스 규칙은 장바구니에 제품 추가, 장바구니에서 제품 제거 등과 같은 각 트랜잭션이 완료될 때 적용됩니다. 예 — 장바구니 총 가격은 모든 제품 가격의 합계와 일치해야 합니다. 카트.

집계 내에서 강력한 일관성(트랜잭션의 ACID 속성의 의미론)이 적용됩니다.

도메인 서비스:

때때로 그것은 단지 사물이나 명사가 아닙니다. 동사 또는 비즈니스 프로세스를 도메인 서비스로 모델링할 수도 있습니다.

전자 상거래에서 다른 입력을 받아 다른 가격 책정 알고리즘을 사용하는 ProductPricer 는 도메인 서비스로 모델링할 수 있습니다.

이와 관련된 코드를 보려면 다음을 확인하세요.

https://github.com/sandeepjagtap/ddd-workshop

참고문헌

  • Eric Evans의 Domain Driven Desing 책

https://medium.com/swlh/microservices-poweredby-domain-driven-design-6160fcac5409 에도 게시됨

https://hackernoon.com/implementing-domain-driven-design-for-microservices-dy1l31iw

Authors get paid when people like you upvote their post.
If you enjoyed what you read here, create your account today and start earning FREE STEEM!
Sort Order:  

[광고] STEEM 개발자 커뮤니티에 참여 하시면, 다양한 혜택을 받을 수 있습니다.