제한된 컨텍스트 간의 상호 작용이 "개방 된 폐쇄적 인 원리"를 손상시킬 수 있다는 점을 고려하면 일반적으로 상반 관계입니까?

Question

나는 경계가있는 컨텍스트 사이의 상호 작용을 구현하고 있습니다. "여하튼"불완전한 폐쇄 원칙을 깨닫고 그것이 BC 설계의 자연스러운 결과인지 또는 고려해야 할 일반적인 트레이드 오프인지 또는 설계 실패인지 여부는 확실하지 않습니다.

일부 항목이있는 장바구니에서 장보기를 만들 수있는 BC 매장을 고려하십시오. 생성 된 주문은 OrderItem으로 구성되며 각각 ItemSpecification 값 개체 인터페이스 ProductSpecification 또는 FooServiceSpecification과 같은 다양한 유형 중 하나를 포함하며 불변 값을 보호하고 일부 데이터를 포함합니다. 주문이 생성되면 다른 BC에서 수신 할 수있는 비동기 이벤트가 방출됩니다.

비동기 이벤트는 순서가 지정되지 않고 OrderDTO 객체가 들어있는 (직렬화 된) OrderCreatedEvent 객체로 표시되며 모든 BC가 코어에 의존 할 수 있도록 코어 네임 스페이스에 모두 배치됩니다. 방법. 지금까지의 모든 좋은 점 :

OrderItemDTO에는 모든 유형의 사양에 대해 구현해야하는 ItemSpecificationDTO 인터페이스가 있어야합니다. 내 ItemSpecification VO (다른 VO/Entity in Order와 마찬가지로)는 실제적으로 쉬운 변환을 달성하기 위해 toCoreDTO() 방법을 사용하며 새로운 ItemSpecification을 구현하기가 상대적으로 어렵고 DTO에 따라 구현하는 것을 잊어 버립니다. 아마 괜찮을거야.

하지만 그 이벤트를 듣는 다른 BC들은 어떻습니까? 모든 BC에서이 이벤트는 AntiCorruption Layer로 변환되어야하며 BC는 일부 유형의 ItemSpecificationDTO에만 관심이있을 수 있으며 해당 특정 BC에 중요한 다양한 값 객체로 변환 할 수 있습니다. 당신은 그 시스템을 수정하는 없이 시스템의 동작을 확장 할 수 있어야한다

:

으로 삼촌 밥은 재치 OCP에 대해 말한다.

하지만 내가 특별히 CoreDTO에서 그 새로운 유형을 변환하기 위해 필요한이 새로운 유형에 관심이있을 수있는 모든 BC에 대한 ItemSpecification의 새로운 유형을 구현할 때 (좋아 나는 각 BC에서 번역에 대한 몇 가지 추상화를 쓸 수 그래서 나는 if ($ x instanceof X)를 추가하는 것과 같은 것을 수정하지 않고 코드를 추가하는 것입니다. 하지만 여전히 새로운 유형의 ItemSpecification을 추가함으로써 다른 BC에서는 적절한 확장을해야합니다 (그리고 이상적인 세상에 살지 않기 때문에 뭔가를 수정할 수도 있습니다).

나는 그것에 대해 어떻게 생각해야할지 모르겠다. 전체 DDD 방식의 단점은 무엇입니까? 다른 BC에서는 무엇을, 어디서, 어떻게 확장해야하는지에 대한 사냥이 기술적 인 문제가 아니라 도메인 요구에 의해 추진되기 때문에 실제로 기능 할 수 있습니까? 그것은 옳은 것처럼 보인다. 결국, 나는 도메인 중심의 디자인을하려고 노력하고있다 :-)하지만 그것은 나에게도 역시 위험한 것처럼 보인다. 언젠가는 다른 BC를 업데이트하는 것을 잊을 수 있고, 나쁜 일이 일어날 까봐 두렵습니다. 그러나 그 이유는 아마도 "나는 두려움"이 속해야하는 영역 전문가 역할의 상당 부분을 차지하기 때문일 것입니다. 내 문제가 의자 두 대에 그냥 앉아 있나? 아니면 내가 잘못한 게 있니? :-)

Answer 1

이 주제에 대한 흥미로운 내용이 많이 있지만, 여기서는 제한된 컨텍스트의 특정 측면에 집중하려고합니다.

즉, 이유 때문에 제한되어 있습니다. 마찬가지로, 모델들 사이의 경계/이러한 맥락에 대한 이해가 있어야합니다. 두 컨텍스트는 관련성이 있더라도 부분적으로 공유 될 수있는 데이터에서도 시스템에 대한 다른 시각을 가져야합니다.

"경계 된 컨텍스트"가 동일한 모델에서 작동하고 싶습니다. 당신은 누구나 볼 수 있고 명백하게 이해할 수있는 "핵심"모델을 만들었습니다. 이 경우, 다른 컨텍스트를 사용하면 얻을 수있는 이점을 잃어 버렸다고 주장 할 수 있습니다. 하나의 모델로 하나의 큰 응용 프로그램을 만드는 것입니다.

이 문제를 해결하려면 중앙/핵심 모델을 제거하고 다른 컨텍스트/서비스에서 "로컬"(경계) 모델을 사용해야한다고 생각합니다. 다른 구성 요소와 통신 할 필요가있을 때, 그 중 한쪽 또는 양쪽 당사자가 지시 한 프로토콜을 정의해야합니다.

예를 들어 쇼핑 카트는 주문을 생성하기 위해 백엔드 시스템의 제품 ID를 알아야 할 수도 있습니다. 그러나 백엔드 시스템은 장바구니가 주문에 대해 (자체 모델에서) 알기 위해 사용하는 모델을 알 필요가 없습니다.