DDD 경계 컨텍스트 및 도메인?


16

나는 10의 데이터베이스 테이블 (집계, 엔터티 / 값 객체)으로 DDD를 적용하는 비교적 복잡한 응용 프로그램에서 일하고 있습니다. 이 시점에서 기본적으로 DDD-Lite 인 것으로 보이며 응용 프로그램 / 도메인 서비스, 도메인 모델 (엔티티, 값 개체) 및 리포지토리가 있음을 의미합니다.

나는 DDD 구현 책을 집어 들었고 그가 언급 한 첫 번째 것은 DDD를 시작할 때 일반적으로 발생하는 첫 번째 실수로 누락 된 DDD-Lite 및 Bounded Contexts 및 Domain Events입니다.

현재 Aggregate 관계로 도메인 모델을 구성하고 네임 스페이스를 사용하여 시연하려고 시도했습니다.

도메인 모델 프로젝트를 별도의 경계 컨텍스트 (아직)로 분리하는 것과 관련된 이점 / 단점을 보지 못했습니다. 아마도 나중에 분명해질 것이지만 경계 컨텍스트 (및 하위 도메인 등이 묶인 경우)에 대한 실제 피드백을 원합니다.


별도의 경계 컨텍스트를 정의하는 유일한 것은 언어학과 관련 운영상의 차이를 구별 할 필요가 있다는 것입니다. 즉, 한 영역에서는 제품이라고하고 다른 영역에서는 제품이라고하지만 서로 다르므로 두 제품이 필요합니다. 동일한 모델 (같은 이름 등)에 있지 않아야합니다. 그렇다면 이름이 미묘하게 다른 의미를 나타내도록 이름을 변경하지 않는 이유는 무엇입니까? 그것들을 모두 다룰 하나의 모델을 가질 수 있습니다. 하위 도메인은 자연 스럽지만 현재 제한된 컨텍스트가 표시되지 않습니다. 그냥 ... 큰 소리로 여기 생각
— 애슐리을 Aitken

도메인을 컨텍스트에서 분할하는 것이 왜 수익성이 좋은지 이미 알고 있다고 생각합니다. 따라서 현재 유용한 것은 컨텍스트를 식별하고 컨텍스트의 경계를 정의하는 올바른 방법입니다. 방법은 다음과 같습니다. medium.com/@wrong.about/…
— Zapadlo

답변:


20

여러 부서가있는 회사를 생각해보십시오.

  • 소프트웨어 개발
  • HR
  • 회계

이러한 모든 비즈니스 영역을 표현할 수있는 사용자 모델을 제안 할 수 있습니까? User 엔터티가 각각 어떻게 보일지 생각해보십시오. 아마도 세 가지 다른 엔티티로 나뉩니다.

  • 개발자
  • 종업원
  • 수취인

각 상황에서 사용자를 인스턴스화하려는 노력은 상당히 다릅니다. 아마도 다음과 같습니다.

  • 신입 사원 (ssn, 이름, 가입 날짜, 생년월일, 성별)
  • 새로운 개발자 (직원, 워크 스테이션, 자격 증명)
  • 새로운 수취인 (직원, 역할)

예를 실례합니다. 적절한 도메인 모델이 없으면 정확하게 설명하기 어렵습니다

순진한 구현을 사용하고 단일 사용자 엔터티를 사용한 경우 결국에는 사용자를 완전히 표현할 수 없었기 때문에 게터와 세터로 가득한 빈혈 데이터 모델이 될 것입니다.

비즈니스에는 명확한 경계가 있으므로 그러한 방식으로 모델링하는 것이 유용합니다. 급여 시스템의 사용자 대 게임 사용자는 동일한 그랜드 시스템에 속해 있어도 매우 다릅니다.

다른 방식으로 생각-이제 개발자 관리 코드를 작성하여 매우 가볍고 나머지 시스템과 독립적으로 만들 수 있습니다. 적은 수하물로 더 정확한 유형을 사용할 수 있습니다. 결국 자체 응용 프로그램으로 추출 될 수있는 더 작은 하위 시스템을 구축하는 단계입니다.


3 BC의 다양한 요구를 설명하는 데 도움이되는 지원 사례에 감사드립니다.
— lko

나는이 개념을 보는 것에 익숙해하지 않는 방법 : 일반적으로,은 Employee하지 않은 것입니다 User가, 이User . 이는 User단순히 개인이 조직 내에서 하나 이상의 애플리케이션에 로그인하고 액세스 할 수있는 엔티티입니다. 그리고 Employee항상을 가지고있는 것은 아닙니다 User. 또한 일반적으로 다른 부서에 대한 간단한 응용 프로그램을 얻지 못합니다. 일반적으로 각 부서에는 자체 도메인 모델이 포함 된 자체 앱이 있습니다. 따라서 나 에게이 답변은 동일한 코드베이스에 별도의 경계 컨텍스트가 있어야한다는 것을 분명히하는 데 도움이되지 않습니다.
— Rogério

@ Rogério 귀하의 이의 제기는 실제로 모든 경계 컨텍스트 내에서 사용되는 유비쿼터스 언어를 올바르게 정의하는 것이 중요한 이유에 대한 아름다운 예입니다.
— MauganRa

고객 관리 시스템이 있거나 주문을 요청하기 위해 전화를 걸거나 청구 등을 할 때 궁금합니다. 적절한 부서로 이동하는 동안 보류됩니다. 각 부서의 도메인 지식은 이러한 시나리오에서 고객의 성가심에 크게 영향을 미칩니다. 아마도 우리는 이러한 맥락들 사이의 분리를 강요했다고 DDD를 비난 할 수 있습니다.
— Andez

16

또 다른 예를들 수 있습니다. 전자 상거래 시스템이 있다고 가정 해보십시오. 거기에 제품이 있지만 제품은 최소한 두 가지 다른 도메인의 일부가됩니다.

  • 제품 설명 및 모든 속성을 유지하는 제품 카탈로그
  • 제품 재고 레벨이있는 ​​재고

두 도메인 모두에 대해 하나의 경계 컨텍스트가있는 경우, 상호 참조를 시작하기 때문에 솔루션이 신속하게 큰 진흙 덩어리가 될 수 있습니다. 결국에는 더 이상 두 개의 도메인이 없습니다. 제품 재고는 제품 카탈로그 참조와 함께 손상되며 그 반대도 마찬가지입니다. 그 결과 다른 도메인을 건드리지 않고 한 도메인을 변경할 수는 없습니다.이 도메인이 필요하지 않다는 것을 완전히 알고 있습니다. 모델은 서로 의존하고 밀접하게 결합되며 구현에 의존하는 나쁜 방식으로 의존합니다.

그러나 두 가지 경계 컨텍스트가있는 경우 통신 채널을 명확하게 유지하자마자 한 도메인에서 수행 한 모든 변경 사항이 다른 도메인에 영향을 미치지 않습니다. 데이터 복제가 필요하지만 손실 된 컴포넌트 기반 애플리케이션에 대해 지불하는 비용이 가장 적습니다. 도메인 이벤트를 사용하여 도메인이 서로 대화 할 수 있습니다. SOA 기반 애플리케이션을 처음에 계획하지 않더라도 도메인 이벤트에 대한 전송을 변경하고 아이디어를 그대로 유지하므로 상대적으로 적은 노력으로 필요할 때 해당 레벨까지 확장 할 수 있습니다.

업데이트 : Eric Evans의 SkillsMatter에 대한 유용한 기술 캐스트가 있습니다. 그는 몇몇 맹인이 그들의 관점에서 코끼리를 묘사 할 때, 옛 이야기와 유사하다. 각 사람은 코끼리의 일부만 만질 수 있기 때문에 "나무", "벽", "뱀", "로프"라고 묘사합니다. 그리고 그 사람들은 각자의 맥락 안에 있습니다. 한정된 맥락은 어디에나있는 언어가 존재하는 곳입니다. 문맥 밖에서 이러한 용어는 완전히 다른 의미를 가질 수 있지만 문맥 내에서 언어는 여러 도메인에서 동일합니다. 그레그 영은 가장 중요한 기본 개념이 여기에 설명되어 있기 때문에 11 장부터 블루 북을 읽을 것을 강력히 제안합니다. 이 책의 시작 부분에서 전술 패턴에 중점을 둔이 "DDD-light"접근 방식은 매우 일반적입니다.


1
중복을 키우기 위해 +1. 처음에는 약간 혼란 스럽지만 ( "이 잘못하고 있습니까?!") 많은 경우에있어 자연 스럽습니다.
— Adrian Schneider

이 시나리오에서 이러한 Product클래스는 모두 동일한 ID를 가정적으로 공유합니까 (예 : 별도의 BC 테이블 둘 다 단일 제품 ID를 가진 테이블에 대한 외래 키를 가짐)? 아마도 도메인 이벤트와 통신 할 때 해당 ID를 사용할 수 있습니까?
— lko

1
선택한 스토리지에 따라 다릅니다. 도메인 간 참조를 위해 기술 ID를 사용할 필요는 없습니다. 상호 컨텍스트 통신을하는 것도 좋지 않습니다.
— Alexey Zimarev

1
파란 책을 선반에서 꺼내고 그 이후의 장을 읽을
— 때가 된 것 같습니다
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.